[Python-3000] Need help completing ABC pep (original) (raw)

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

More information about the Python-3000 mailing list