On 3/15/2011 11:17 AM, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
<fuzzy...@voidspace.org.uk> wrote:
On 15/03/2011 07:59, Nick Coghlan wrote:
While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore to the
*end* (as_dict_, replace_, make_) as is sometimes done for code that
needs to avoid conflicting with a keyword.
Namespace collisions with actual fields would remain unlikely, while
pydoc would pick up the new names correctly.
Although it's a backwards incompatible change. Teaching pydoc to recognise
the private methods isn't.
If we can find a good way to do it, making pydoc smarter would
definitely be a nicer option.
If we went the "moving the underscore" route, the old names would
indeed have to remain for compatibility.
However, pydoc left alone would only pick up (and publicize) the new
names. One can argue that since the methods are not really private, they
should have had a trailing rather than leading underscore in the first
place. Other module classes have recently had method names aliased and
deprecated for eventual removal, so this would not be a unique move,
though a class factory is slightly different from a class.
--
Terry Jan Reedy
_______________________________________________
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
