[Python-3000] Need help completing ABC pep

[Guido van Rossum]

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)
set instance.

> > > * "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/)