Import question 
Author Message
 Import question

I find it annoying to force my code to be imported only from sys.path.
Is there a way to import code from any path without having to add it
to sys.path?

e.g. Why can't we do import c:\\myapppath\\myutil and then that would
make myutil be loaded.

costas



Thu, 06 Nov 2003 03:36:09 GMT  
 Import question
    Not easil, but you can.look at the 'imp' module in the standard library.
Really, I'd just deal with the annoyance. :) Generally, I don't have any
need to add anything tothe sys.path. Any modules my programs have to load
are either in the directory of my main program file, or in a sub-directory
which I set up as a package, and that lets everything behave nicely without
sys.path bloat,.. or any unfriendly hacks.

--Stephen

--
(replace 'NOSPAM' with 'seraph' to respond in email)


Quote:
> I find it annoying to force my code to be imported only from sys.path.
> Is there a way to import code from any path without having to add it
> to sys.path?

> e.g. Why can't we do import c:\\myapppath\\myutil and then that would
> make myutil be loaded.

> costas



Thu, 06 Nov 2003 13:15:45 GMT  
 Import question

Quote:
> I find it annoying to force my code to be imported only from sys.path.
> Is there a way to import code from any path without having to add it
> to sys.path?

Sure!  Built-in module imp gives you all the bricks you need for
the purpose of building this particular outhouse:-).

Quote:
> e.g. Why can't we do import c:\\myapppath\\myutil and then that would
> make myutil be loaded.

...under what name?  If just undecorated 'myutil', this runs into
potential conflicts.  What happens if your module a.py has:

    import c:\\fora\\peep

and your module b.py has

    import c:\\forb\\peep

WHICH one of the two modules, if either, becomes the one
referred to by sys.modules['peep']?  The potential for deep
ambiguity seems large to me, and Python's strategy when no
obvious strategy exists to resolve the ambiguity is generally
to NOT guess, but rather force explicit specification.

An advanced python programmer will easily build a custom
import strategy for those exceedingly rare cases where the
obvious approach of altering sys.path is not desired.  A less
advanced user is best not encouraged to hardwire module
paths in his or her source code, not a very good practice.

Note that a reasonably common retort when somebody asks
for a built-in functionality X and is reminded that X is easy
to build with existing bricks is "but if X is not standard I
can't easily use it in my programs intended for distribution".
Quite apart from the issue of the general merit of this stance,
it clearly doesn't apply here -- programs intended for such
distribution would be PARTICULARLY wise to avoid having
any hard-coded absolute path:-).

Alex



Thu, 06 Nov 2003 16:06:48 GMT  
 Import question

Quote:

>...under what name?  If just undecorated 'myutil', this runs into
>potential conflicts.  What happens if your module a.py has:

>    import c:\\fora\\peep

>and your module b.py has

>    import c:\\forb\\peep

>WHICH one of the two modules, if either, becomes the one
>referred to by sys.modules['peep']?  The potential for deep
>ambiguity seems large to me, and Python's strategy when no
>obvious strategy exists to resolve the ambiguity is generally
>to NOT guess, but rather force explicit specification.

>An advanced Python programmer will easily build a custom
>import strategy for those exceedingly rare cases where the
>obvious approach of altering sys.path is not desired.  A less
>advanced user is best not encouraged to hardwire module
>paths in his or her source code, not a very good practice.

There is a solution for both issues you raise in my dream Python.

Assume there is a myfile.ini file and an ini file reader that allows
you to configure your system at installation time.

import ini
aPath1 = ini.getIni('path1','myfile.ini')
aPath2 = ini.getIni('path2','myfile.ini')

import aPath1 + 'peep' as peep1
import aPath2 + 'peep' as peep2

Of course the syntax above is bogus since import does not accept an
expression for the module name. And the reload() would also work with
no changes.

Another advantage is the fact that you are specific about which module
to load. Without the path name you can have in your sys.path two
modules of the same name and un-intenionally load the wrong one. A
more insidious problem than hardwiring.

Costas

P.s. I don't believe hardwiring is the domain of "less advanced"
users. I do it all the time for throwaway code as I am sure you have.



Thu, 06 Nov 2003 19:03:03 GMT  
 Import question

    ...

Quote:
> There is a solution for both issues you raise in my dream Python.

> Assume there is a myfile.ini file and an ini file reader that allows
> you to configure your system at installation time.

> import ini
> aPath1 = ini.getIni('path1','myfile.ini')
> aPath2 = ini.getIni('path2','myfile.ini')

> import aPath1 + 'peep' as peep1
> import aPath2 + 'peep' as peep2

And this would affect sys.modules how...?  Remember, the
'as' only affects the CURRENT binding of a module object,
NOT the way in which it's recorded in sys.modules.

Quote:
> Of course the syntax above is bogus since import does not accept an
> expression for the module name. And the reload() would also work with
> no changes.

Syntax sugar is no biggie.  _AVOIDING_ undesired reload seems
the (relatively) biggie:-).

Anyway, here, syntax-sugar details apart, is your "dream Python
importer" -- place it in builtins in your site.py, or whatever:

import imp, sys
def CMimport(modulePath, moduleFilename, moduleRealname=None):
    if moduleRealname is None: moduleRealname = moduleFilename
    try: return sys.modules[moduleRealname]
    except KeyError:
        flob, pthnm, desc = imp.find_module(moduleFilename, [modulePath])
        try:
            modobj = imp.load_module(moduleRealname, flob, pthnm, desc)
        finally:
            if flob is not None: flob.close()
        return modobj

Your dream example becomes:

import ini
aPath1 = ini.getIni('path1','myfile.ini')
aPath2 = ini.getIni('path2','myfile.ini')

peep1 = CMimport(aPath1, 'peep', 'peep1')
peep2 = CMimport(aPath1, 'peep', 'peep2')

Close enough for you...?  If you want to suggest this as a core built-in
or something, feel free to use this trivial code in the patch you'll submit
to Sourceforge.  As for me, I'm quite happy to use the standard import
on the 99+% of occasions where it serves me just fine, since it's about
5 minutes to do my own importing tricks (such as this one) on the
less than 1% of cases where I prefer non-standard behavior.

This doesn't support packages, BTW -- that takes more work.  And I
hope you'll agree packages are best left to their current behavior, in
any case (otherwise, you'll welcome to extend this to support them!).

Quote:
> Another advantage is the fact that you are specific about which module
> to load. Without the path name you can have in your sys.path two
> modules of the same name and un-intenionally load the wrong one. A
> more insidious problem than hardwiring.

Just like for the system PATH, &c, I see this not as "an insidious problem"
but as an important technique for temporarily substituting a polymorphic
version of some existing program/module/&c for debugging purposes.

Quote:
> P.s. I don't believe hardwiring is the domain of "less advanced"
> users. I do it all the time for throwaway code as I am sure you have.

Yes, but NOT for code intended to be distributed (sort of the reverse
of "throwaway"!-), which was part of my point -- since it's so easy to
tweak importing behavior, if you often rely on this tweak _for your
own throwaway programs_ just install it from your site.py -- the only
'advantage' of having it as default behavior would be if the technique
was worth supporting in programs intended for wide distribution...

Alex



Thu, 06 Nov 2003 23:28:05 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. import/from import question

2. C5a importing question

3. import question

4. Tkinter + import question

5. import * question

6. import question

7. import question

8. trivial import question

9. import question

10. newbie import question

11. Module import questions

12. importing question

 

 
Powered by phpBB® Forum Software