[Python-Dev] Assignment to __class__ of module? (Autoloading? (Making Queue.Queue easier to use))
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 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 at python.org
More information about the Python-Dev