[Python-3000] Question about PEP 3001 and fixing API flaws

[BJörn Lindqvist]

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 -> 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
>


-- 
mvh Björn