[Python-3000] PEP 3119 - Introducing Abstract Base Classes

Jim Jewett jimjjewett at gmail.com
Tue May 1 01:37:25 CEST 2007


On 4/30/07, Barry Warsaw <barry at python.org> wrote:
> On Apr 27, 2007, at 1:10 PM, Jim Jewett wrote:
> > On 4/27/07, Barry Warsaw <barry at python.org> wrote:

> >> Finally, I'm concerned with the "weight" of adding ABCs to all the
> >> built-in types.

> > What if the builtin types did not initially derive from any ABC, but
> > were added (through an issubclass override) when the abc module was
> > imported?

> That would allow for some unfortunately global side-effects.  Say I
> happen to import your library that imports abc.  Now all the built-in
> types in my entire application get globally changed.  I'm also not
> sure how you'd implement that.

I don't see how these side-effects could ever be detected, except to
the extent that issubclass overrides are inherently dangerous.

I see it something like

# module abc.py

class Integer()...
    ...

Integer.register(int)
Integer.register(long)

After that, int (and long) are changed only by the addition of an
extra reference count; their __bases__ and __mro__ are utterly
unchanged.   But

    isinstance(int, Integer)

is now True.  Yes, this is global -- but the only way to detect it is
to have a reference to Integer, which implies having already relied on
the ABC framework.

-jJ


More information about the Python-3000 mailing list