[Python-3000] Question about PEP 3001 and fixing API flaws (original) (raw)

Steven Bethard steven.bethard at gmail.com
Wed Mar 21 20:38:32 CET 2007

On 3/14/07, BJörn Lindqvist <bjourne at gmail.com> wrote:

So I wonder what is the policy for fixing mistakes in the API design?

In general, I think if you can warn about it in 2.6 or you can add to 2to3 so that this gets automatically fixed, then it's okay to fix the API.

Is a PEP really needed? For example, here are some bugs in the threading module:

activeCount() # Redundant, use len(threading.enumerate())

Removing this should be alright as long as Python 2.6 warns about it with the -Wpy3k flag.

currentThread() # PEP8 -> currentthread() class local # PEP8 -> class Local

PEP 3108 (http://www.python.org/dev/peps/pep-3108/) and PEP 364 (http://www.python.org/dev/peps/pep-0364/) address some of the issues in renaming things, though I don't think they address renaming anything but modules. Of course, for Python 2.6 it's pretty simple to make one spelling of the class/function/method an alias of the other. But I don't see an obvious way to do this except manually. PEP 364 should probably address this.

For another example, take the Telnet class in the telnetlib module. It has a method setoptionnegotiationcallback() which takes a function that will be called for each telnet option read. The default behaviour for the Telnet class is to refuse all negotiation requests, but using a negotiation callback you can override that.

However, using a callback does not work so well because the function acting on the telnet options read still needs to reference the Telnet class to get hold of negotiation data using readsbdata(). The problem is non-lethal but a small annoyance to advanced Telnet users. See SourceForge patches #1520081, #664020 and #1678077. The right design would have been to have a method (handleoption) in the class that handles all options and, by default, refuses them. Users of the Telnet class could then subclass Telnet and override the handleoption method to implement their application specific option handling.

Seems like this could be done now (for Python 2.6), no? Just factor out the code that decides whether or not to call self.option_callback into a handle_option() method and call that. I'm not sure I see how Python 3000 comes into it...

STeVe

I'm not in-sane. Indeed, I am so far out of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

More information about the Python-3000 mailing list