[Import-sig] Re: Proposal for a modified import mechanism.

[Gordon McMillan]

eric wrote:

[Frederic Giacometti]

> > 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 
burden.


- Gordon