On 3/15/2011 11:17 AM, Nick Coghlan wrote: > On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord > <fuzzyman at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4