[Import-sig] Re: Proposal for a modified import mechanism.
Sat, 10 Nov 2001 16:50:32 -0500
> > because the obvious reason of increased name space collision,
> > increased run-time overhead etc...
> I'm missing something here because I don't understand why this
> increases name space collision.
Currently, os.py in a package masks the real one from
anywhere inside the package. This would extend that to
anywhere inside any nested subpackage. Whether that's a
"neat" or a "dirty" trick is pretty subjective. The wider the
namespace you can trample on, the more it tends to be "dirty".
> If the objection is to the fact
> that SciPy can have a version of Numeric in it that masks a
> Numeric installed in site-packages, I guess I consider this a
> feature, not a bug. Afterall, this is already the behavior for
> single level packages, extending it to multi-level packages seems
> natural. If this isn't your objection, please explain.
Well, it's a feature that can crash Python. If the package
(which the user has, and you have a hijacked, incompatible
copy of) contains an extension module, all kinds of nasty
things can happen when both are loaded.
Submit patches to the package authors, or require a specific
version, or write a wrapper that adapts to different versions or
fork or do without. This is definitely a dirty trick.
> The current runtime overhead isn't so bad.
Under anything near normal usage, no - packages structures
are nearly always shallow. It wouldn't be much work to
construct a case where time spent in import doubled, however.
When the "try relative, then try absolute" strategy was
introduced with packages, it added insignificant overhead. It's
not so insignificant now. When (and if) the standard library
moves to a package structure, it's possilbe it will be seen as a