[Python-3000] Question about PEP 3001 and fixing API flaws
BJörn Lindqvist
bjourne at gmail.com
Wed Mar 14 22:20:11 CET 2007
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 -> current_thread()
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 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.
Can or should API bugs like these be fixed for Python 3.0?
--
mvh Björn
More information about the Python-3000
mailing list