[Python-Dev] Breaking undocumented API (original) (raw)

Łukasz Langa lukasz at langa.pl
Thu Nov 11 15:45:47 CET 2010

Am 08.11.2010 23:07, schrieb Raymond Hettinger:

Some sense needs to be applied to the decision. Google's code search is great for showing how people actually have used a module in real world code. If that shows that people are accessing and/or changing an attribute, it probably needs to remain exposed. In the absence of a code search, good guesses can be made about what someone might reasonably and usefully be accessing (i.e. glob0 isn't likely).

Danger, Will Robinson!

I just tried to use that to determine if I could consider moving a module-wide constant in configparser to the parser instance (to enable customization).

Search on code.google.com returned me four incompatible result sets within 30 minutes. One had only two entries whereas another had 7 pages of results.

Search using www.google.com/codesearch found 3 pages of results different than the search on Google Code. The best part is that codesearch found some occurences on Google Code which Google Code's own search didn't.

None of them returned sourceforge.net results whereas search on Koders.com found occurences only on SourceForge.

The idea to use a code search engine is ingenious but the current tools are not yet reliable enough for the task.

For example, when the pprint rewrite is finally ready, if there is an incompatible API change, I expect that a new clean class will be offered, but that the old will be left in-place so that tons of existing code won't break). Unrelated but that's the way I'm doing it.

More information about the Python-Dev mailing list