At 04:02 PM 10/13/2005 +0100, Michael Hudson wrote: >Greg Ewing <[EMAIL PROTECTED]> 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.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
