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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
