[Python-3000] PEP 3119 - Introducing Abstract Base Classes
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()...
> 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