[Python-Dev] Assignment to class of module? (Autoloading? (Making Queue.Queue easier to use)) (original) (raw)

Eyal Lotem eyal.lotem at gmail.com
Thu Oct 13 19:52:32 CEST 2005

Why not lazily import modules by importing them when they are needed (i.e inside functions), and not in the top-level module scope?

On 10/13/05, Phillip J. Eby <pje at telecommunity.com> wrote:

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 tpfree. (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 at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/eyal.lotem%40gmail.com

More information about the Python-Dev mailing list