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

[Prabhu Ramachandran]

>>>>> "GMcM" == Gordon McMillan <gmcm@hypernet.com> writes:

[snip]

    >> Also, if someone has the gall to hijack os.py at the top of
    >> your package directory structure, it seems very likely you want
    >> this new behavior everywhere within your package.

    GMcM> Perhaps. The trouble is that under this proposal there is no
    GMcM> way to get to the real os.py, even when you know what's
    GMcM> going on. The proposal doesn't fix a flaw in today's import,
    GMcM> it extends the flaw. If there were different ways of
    GMcM> spelling "absolute" and "relative", you would get what you
    GMcM> want, and I would get what I want.

I agree.  My proposal was simply a way to clear up my problem.  I'll
admit I didn't think of the bigger picture.  What do you propose?  You
mentioned that import should be narrower in its search, rimport a
hybrid and rrimport do what i asked for.  This does, somewhat atleast
address the problem.

As regards getting the real os.py I think the best possible way would
be to put all standard modules into a package called std or something.
This need not necessarily require a package structure for standard
modules.  import could simply be modified to see if someone has asked
for std.foo and it will only provide the os.py that is found on
sys.path.  Of course a terrorist package could stick in a nasty .pth
file and expose its os.py as the _real_ one which is a problem but I
guess its unlikely someone would want to create such a bad package.

[snip]
 
    GMcM> And it's my contention that the problem this proposal
    GMcM> "fixes" is a symptom of a deeper problem - the fact that the
    GMcM> import namespace has a concept of "relative" but no way to
    GMcM> spell it.  The proposal makes some things work, and makes
    GMcM> others worse.

I understand but apart from concerns on speed (for which I really
haven't seen real examples) and concerns on issues on things like
exposing os.py, I really don't see anything becoming 'worse'.
However, I agree wholeheartedly that the import mechanism needs a
re-think and am willing to help in my limited capacity. :)
 
    GMcM> Prabhu objects to your numbers. Perhaps he's using the
    GMcM> standard xml package, and you're using _xmlplus? The latter
    GMcM> is vastly more complex.

Indeed, I am using the standard xml package.  I don't have the
_xmlplus package installed.  So I might be wrong but I really can't
believe that there is a 3.5 fold speed reduction.  I'd like to hear a
confirmation from Eric.  Anyway, is there some other large package
that you'd like me to test with.

prabhu