On 3/14/07, BJörn Lindqvist <[EMAIL PROTECTED]> 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 -> current_thread() > 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 set_option_negotiation_callback() 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 read_sb_data(). 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 (handle_option) in > the class that handles all options and, by default, refuses > them. Users of the Telnet class could then subclass Telnet and > override the handle_option 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
