[Python-3000] Need help completing ABC pep
jimjjewett at gmail.com
Sun Apr 22 06:20:43 CEST 2007
On 4/19/07, Guido van Rossum <guido at python.org> wrote:
> On 4/19/07, Brett Cannon <brett at python.org> wrote:
> > On 4/19/07, Guido van Rossum <guido at python.org> wrote:
> > > I've started a PEP on Abstract Base Classes (ABCs), PEP 3119:
> > * "Should we also implement the issubset and issuperset methods found
> > on the set type in Python 2? As these are just aliases for __le__ and
> > __ge__, I'm tempted to leave these out."
> > Leave them out. Not terribly needed plus it is better to start out
> > small. They can easily be added later if called for.
I think the names are more sensible than repurposing the numeric
operators. The "concrete" implementation can just forward to other
name, so it doesn't cost much.
> 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.
You could use a variant of the numeric operator resolution.
The left class wins, unless the right class is a subclass of the left.
If this class does not have a constructor that accepts an iterable,
(maybe fall back to the other class, then) fall back to a builtin set.
Going back to the PEP itself, in the ABC support framework, I would change:
"We define the following four new built-in objects that help defining ABCs:"
"We define the following four new objects (in module abc) that help
and in the @abstractmethod description,
"Such a method may be called"
"These abstract methods may still be called"
In the Hashable section:
> Another constraint is that hashable objects, once created,
> should never change their value (as compared by ==) or their hash
> value. If a class cannot guarantee this, it should not derive from
> Hashable; if it cannot guarantee this for certain instances only,
> __hash__ for those instances should raise a TypeError exception.
Why not just return -1 (unless/until the value is stable)? Is the -1
special case being phased out too?
I would say that Searchable might be worth separating into a Container
subclass, but don't worry about the speed differences. Many
containers are small enough that constant effects are more important
than big-O. When big-O does matter, then the user may well want to
distinguish between the O(1) and O(log N) case. I think this gets
detailed enough that it isn't worth putting in the common library.
Why must a HashableSet or MutableSet be composable? If this is
because you figure any useful set has those properties (and I don't
think so, when doing uniquification), then Set and ComposableSet
should become BasicSet and Set?
Note that in the current sandbox sandbox (which doesn't have
*Ordered), the name BasicSet is used for a Set which isn't Sized.
(Except that Set doesn't actually inherit from BasicSet, as I assume
it should do.)
Continuing with the current sandbox
Why must @abstractmethod come last, when mixed with other decorators?
IterableMapping needs to override __iter__; as written, it returns the
Should Sequence.index take optional start and stop arguments?
def index(self, value, start=0, stop=None):
if stop is None:
stop = len(self)
for i, elem in enumerate(self):
if i < start:
if stop < i:
if elem == value:
More information about the Python-3000