[Python-Dev] Breaking undocumented API
Ł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