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