On 4/19/07, Brett Cannon <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
