[Python-3000] PEP 3119 - Introducing Abstract Base Classes (original) (raw)

Guido van Rossum guido at python.org
Tue May 1 01:43:16 CEST 2007

> > 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.

> On Apr 27, 2007, at 1:10 PM, Jim Jewett wrote: > > 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?

On 4/30/07, Barry Warsaw <barry at python.org> wrote: > 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.

On 4/30/07, Jim Jewett <jimjjewett at gmail.com> wrote:

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.

Right. int (long doesn't exist in py3k!) doesn't change -- the only thing that "changes" is that the question subclass(int, Integer) is answered positively, but since you can't ask that question without first importing Integer (from abc), there is no way that you can detect this as a change. Note that you won't find Integer if you traverse int.mro or int.bases.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list