[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