[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