Prev: unittest basics
Next: reading xml from python
From: Jean-Michel Pichavant on 11 May 2010 08:30
Aur� Gourrier wrote:
> [snip]
> My question is the following: I need to import an external package,
> say numpy, for use in various submodules. So far, I simply do an
> import numpy as _numpy where needed, say sub1module1 and sub2module2.
> This means that I import this package a number of times which doesn't
> seem to be a logical thing to do (?).
No problem at all.
You need numpy in a file, then import numpy at the very beginning of the
file. You have 100 files requiring numpy? you'll end up with 100 'import
numpy' statements, but who cares ? This is perfectly logic and pythonic
in the way it is explicit.

You could reference numpy as member of you rootlib package, but any call
of numpy methods will be prefixed by rootlib.numpy, and you still need a
import rootlib (circular imports since rootlib is importing your
submodules !)


JM

> Aur�
>
>

From: Terry Reedy on 11 May 2010 15:25
On 5/11/2010 8:04 AM, Auré Gourrier wrote:
> Dear all,
>
> I am building a library package of the form:
>
> rootlib
> ---__init__
> ---subpackage1
> ------__init__
> ------sub1module1
> ------sub1module2
> ------...
> ---subpackage2
> ------ __init__
> ------sub2module1
> ------sub2module2
> ------...
>
> My rootlib.__init__ file contains:
>
> __name__ = ...
> __version__ = ...
> __author__ = ...
> __author_email__= ...
> __url__ = ...
> __description__ = ...
>
> import subpackage1
> import subpackage2
>
> __all__ = []
> __all__.extend(['subpackage1','subpackage2'])
>
> My question is the following: I need to import an external package,
say numpy, for use in various submodules. So far, I simply do an import
numpy as _numpy where needed, say sub1module1 and sub2module2. This
means that I import this package a number of times which doesn't seem to
be a logical thing to do (?). In the end, I would like to make this
module a "global" module for my library.

I have a similar package structure and after writing a few submodules, I
developed a template that includes common text, including a couple of
imports that are usually needed. I also made a backup copy of the
template in case I open the template and forget to 'save as
<submodule-name>' before just 'save'ing ;-).

If I had several such imports, and thought the list might expand, I
might make one submodule for imports and then do 'from rootlib.util
import importmod as m' in the template. But I have no need now for such.

Terry Jan Reedy


From: Jean-Michel Pichavant on 12 May 2010 04:26
Terry Reedy wrote:
> On 5/11/2010 8:04 AM, Aur� Gourrier wrote:
> I might make one submodule for imports and then do 'from rootlib.util
> import importmod as m' in the template. But I have no need now for such.
>
> Terry Jan Reedy
>
>
We did that, and we so regret it. After 5 years of intensive dev on that
application (with more than 10 different guys committing in the repos)
this module is now nothing but a real mess.
As soon as someone is writing twice the same import: "Oh I should put
this module into the auto import, it will save 4 sec of my time".

This module is now an inconsistent bunch of imports and global
assignements :( .

JM

 | 
Pages: 1
Prev: unittest basics
Next: reading xml from python