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

BJörn Lindqvist bjourne at gmail.com
Wed Mar 21 19:54:13 CET 2007

No comments at all. :( Did I send the mail to the wrong list?

Either or, I still would like to know what the py3k rules are for repairing broken API:s.

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

I have a question about PEP 3001:

"""The last and most disruptive change is the overhaul of a module's public interface. If a module's interface is to be changed, a justification should be made beforehand, or a PEP should be written. The change must be fully documented as "New in Version 3.0", and the python3warn.py script must know about it.""" It seems like its wording makes it very hard to fix broken or bad stuff in old modules. Many modules are very old and contain lots of legacy stuff that is kept to preserve backwards compatibility. Other modules exposes a non-optimal (or even bad) API because it must not be changed. So I wonder what is the policy for fixing mistakes in the API design? Is a PEP really needed? For example, here are some bugs in the threading module: activeCount() # Redundant, use len(threading.enumerate()) currentThread() # PEP8 -> currentthread() class local # PEP8 -> class Local Is there anything that can be done about it? 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. Can or should API bugs like these be fixed for Python 3.0?

-- mvh Björn

-- mvh Björn

More information about the Python-3000 mailing list