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

[BJörn Lindqvist]

On 3/21/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> 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 that the general consensus? I think I remember having read Raymond
Hettinger complain about to many warnings in 2.6.

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

OK. So every API repair is a two step process? Fix the API in py3k and
then add a warning to 2.6 and update the manual.

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

I think so too. Aliasing names is easy to do, but uglifies things.
Plus, if you do it that way, can you still emit DeprecationWarnings?

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

The patches eliminate the set.option_callback variable and the
Telnetlib.set_option_negotiation_callback() method. The problem has an
extra twist because the old way is mutually exclusive with the new
way. Or well, you could support them both but that would make the
class extra ugly.

-- 
mvh Björn