[Python-Dev] Assignment to __class__ of module? (Autoloading? (Making Queue.Queue easier to use))
Phillip J. Eby
pje at telecommunity.com
Thu Oct 13 19:46:28 CEST 2005
At 04:02 PM 10/13/2005 +0100, Michael Hudson wrote:
>Greg Ewing <greg.ewing at canterbury.ac.nz> writes:
>
> > Phillip J. Eby wrote:
> >> At 01:47 PM 10/13/2005 +1300, Greg Ewing wrote:
> >>
> >>> I'm trying to change the __class__ of a newly-imported
> >>> module to a subclass of types.ModuleType
> >>
> >> It happened in Python 2.3, actually.
> >
> > Is there a discussion anywhere about the reason this was
> > done? It would be useful if this capability could be
> > regained somehow without breaking things.
>
>Well, I think it's undesirable that you be able to do this to, e.g.,
>strings. Modules are something of a greyer area, I guess.
Actually, it's desirable to be *able* to do it for anything. But certainly
for otherwise-immutable objects it can lead to aliasing issues.
For mutable objects, it's *very* desirable, and I think the rules added in
2.3 might have been overly strict, as they disallow you changing any
built-in type to a non built-in type, even if the allocator is the
same. It seems to me the safety check could perhaps be reduced to just
checking whether the old and new classes have the same tp_free. (Apart
from the layout and other inheritance-related checks, I mean.)
(By the way, for an example use case other than modules, note that somebody
wrote an "observables" package that could detect mutation of lists and
dictionaries in Python 2.2 using __class__ changes, which then became
useless as of Python 2.3.)
More information about the Python-Dev
mailing list