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

[Steven Bethard]

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