[Python-3000] Need help completing ABC pep
Guido van Rossum
guido at python.org
Fri Apr 20 20:43:20 CEST 2007
On 4/19/07, Brett Cannon <brett at python.org> wrote:
> > Good point. Now that you mention this, and I don't understand why I
> > didn't already do it this way in sandbox/abc, the check could be made
> > at *class creation time*, and at instantiation time it should just
> > have to make one tiny check.
> I thought you were already doing that. =)
I am now.
> I was just worried that it
> would be prohibitively expensive at class creation time for some short
> script that used mostly stdlib code that happened to use ABCs.
The built-in types can and will use certain shortcuts. :)
> > I doubt that 'set' will be inherited from much (except for trivial
> > stuff) but returning a 'set' does make some sense. Although for
> > trivial subclasses (e.g. adding a different repr or a brand new
> > method) you'd like the results also to be an instance of the subclass.
> > If we could find a way to do that it would be best.
> Well, self.__class__() would work, right? That should resolve
> properly. Or maybe we need that super keyword. =)
No, self.__class__() emphatically does *not* work. The PEP
specifically claims not to define the constructor signatures -- it's
quite possible to implement an object that conforms to the set ABC but
whose constructor does not take a sequence of values. Assuming an
empty constructor always works is unwarranted too. This is why I don't
quite know what to do, except perhaps always returning a (built-in)
> > > * "Should we support all the operations implemented by the Python 2 set type?"
> > >
> > > No, only core methods should be directly supported. Everything else
> > > is just convenience functions. If these can be implemented simply as
> > > concrete methods then fine, but otherwise leave them out.
> > Sure. But one can differ about whether union() is the convenience and
> > __or__() the core, or vice versa. :-)
> So I say base it on ease of implementation. If it can be done
> trivially in five lines of Python code then include it, otherwise let
> the user do it.
OK, for now I'm including |= and the other operators and excluding
union and the other methods. I'm thinking the argument to |= and
friends should be any iterable though. (But not the argument to the
non-inline | operator!) Concrete implementations are trivial.
> > > * "Also pop, popitem, setdefault?"
> > >
> > > Eh, my gut reaction is "no". But you do have 'pop' on MutableSequence.
> > But for sequences it trivially maps on core methods. pop() for
> > mappings is a little more convoluted (how to pick a random key? Just
> > pick the first one I guess?)
> Right, which is why my gut reaction was "no". I don't know how you
> choose. But if you are popping off of a mapping object you should
> know the order will be undefined. I would take your latter
> suggestion: get a list of keys, take the first one and use that as
> what gets popped off.
OK, pop and popitem are back in, as concrete methods.
> > > * Discussing sequences: "What about += and *=?"
> > >
> > > No. Only worth it when a special gain is available by the implementation.
> > OTOH not requiring these gives them fuzzy semantics -- some mutable
> > sequences will return self, others a new object. That's not good. I'd
> > like to standardize self-modifying +=, *=.
> Then I guess you answered your own question. If you were asking about
> semantics I would just follow what lists do.
OK, they're in, as concrete operators.
> See http://haskell.org/onlinereport/prelude-index.html for the Haskell
> 98 report and the prelude (Haskell's version of built-ins). You care
> about the type classes (which they just call "classes" on the page).
> If you follow the links for any of the type classes they will tell you
> exactly what functions must be defined for something to meet that type
> class. Some of them are Haskell-specific, but not all.
One for my copious spare time...
> Umm, Sized? =) Basically, no, I don't have a better suggestion.
I like it.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000