Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #21227 > unrolled thread

Re: Trying to understand 'import' a bit better

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Trying to understand 'import' a bit better Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-03-05 11:40 +0100

#21227 — Re: Trying to understand 'import' a bit better

Frank Millman wrote:
> Hi all
>
> I have been using 'import' for ages without particularly thinking about it - 
> it just works.
>
> Now I am having to think about it a bit harder, and I realise it is a bit 
> more complicated than I had realised - not *that* complicated, but there are 
> some subtleties.
>
> I don't know the correct terminology, but I want to distinguish between the 
> following two scenarios -
>
> 1. A python 'program', that is self contained, has some kind of startup, 
> invokes certain functionality, and then closes.
>
> 2. A python 'library', that exposes functionality to other python programs, 
> but relies on the other program to invoke its functionality.
>
> The first scenario has the following characteristics -
>   - it can consist of a single script or a number of modules
>   - if the latter, the modules can all be in the same directory, or in one 
> or more sub-directories
>   - if they are in sub-directories, the sub-directory must contain 
> __init__.py, and is referred to as a sub-package
>   - the startup script will normally be in the top directory, and will be 
> executed directly by the user
>
> When python executes a script, it automatically places the directory 
> containing the script into 'sys.path'. Therefore the script can import a 
> top-level module using 'import <module>', and a sub-package module using 
> 'import <sub-package>.<module>'.
>
> The second scenario has similar characteristics, except it will not have a 
> startup script. In order for a python program to make use of the library, it 
> has to import it. In order for python to find it, the directory containing 
> it has to be in sys.path. In order for python to recognise the directory as 
> a valid container, it has to contain __init__.py, and is referred to as a 
> package.
>
> To access a module of the package, the python program must use 'import 
> <package>.<module>' (or 'from <package> import <module>'), and to access a 
> sub-package module it must use 'import <package>.<sub-package>.<module>.
>
> So far so uncontroversial (I hope).
>
> The subtlety arises when the package wants to access its own modules. 
> Instead of using 'import <module>' it must use 'import <package>.<module>'. 
> This is because the directory containing the package is in sys.path, but the 
> package itself is not. It is possible to insert the package directory name 
> into sys.path as well, but as was pointed out recently, this is dangerous, 
> because you can end up with the same module imported twice under different 
> names, with potentially disastrous consequences.
>
> Therefore, as I see it, if you are developing a project using scenario 1 
> above, and then want to change it to scenario 2, you have to go through the 
> entire project and change all import references by prepending the package 
> name.
>
> Have I got this right?
>
> Frank Millman
>
>
>
>   
I think you got it right. It happened to me as well, I guess it's a 
classic for program  being promoted into a library.

JM

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web