[Pythonmac-SIG] importing namespaces/modules

[Piet van Oostrum]

>>>>> David Worrall <vip at avatar.com.au> (DW) wrote:

>DW> Hello all,
>DW> I've got a query which is probably obvious for people more  
>DW> experienced than I
>DW> but I can't find any exact reference to it elsewhere.
>DW> It's not mac specific, but hey, I already belong to too many dev  
>DW> groups...   :-)
>DW> The discussion at http://docs.python.org/tut/node11.html is OK but it  
>DW> doesn't really answer my query.

>DW> I note that increasingly programmers are deprecating

>>>>> from module import *

>DW>   in favour of
>>>>> import module

>DW> which is fair enough, as explicit attributes make code more readable.

>DW> Are the functions/classes/whatevers that are imported into the  
>DW> namespace with >>> import module
>DW> but not otherwise referenced, explicitly loaded into the python  
>DW> "workspace" (excuse me, I'm an unrepentant APL programmer)
>DW> including the __doc__ strings etc etc or not?

The whole module is always loaded into memory, no matter what format of
the import statement you use.

>DW> And if so, do they remain in the .pyc image?

Every module has its own .pyc file. The .pyc file of the importing module
only contains the bytecode for the import statement, not the bytecode of
the imported module, because that is in thye .pyc file of the imported
module.

>DW> And after py2app?

I am not very familiar with py2app, but I think it packs up the necessary
.pyc modules into the executable. But I am quite sure it will always pack
the whole .pyc file. It would be unfeasible to extract only a part of a
.pyc file as there will be all kinds of internal references in the module.
Some of the dependencies might be so dynamic that a static analyses would
be unable to detect them.

>DW> In the case where module is quite large (think wx or twisted for eg)
>DW> I'm wondering what are the relative advantages/disadvantages of, for  
>DW> example
>>>>> import twisted
>>>>> class MessageHandler(twisted.internet.protocol.DatagramProtocol):

>DW> compared with
>>>>> from twisted.internet.protocol import DatagramProtocol
>DW> Class MessageHandler(DatagramProtocol):

>DW> other than the obvious easy of reading  
>DW> "twisted.internet.protocol.DatagramProtocol" in a large environment  
>DW> with many imported modules, which is my situation.

The advantages have nothing to do with size. In the above example it is
mainly readability, and maybe name clashes with a DatagramProtocol from
another module. The main reason for
deprecating from module import * is the pollution of your namespace. E.g.

ERRORCODE = -1
SUCCESSCODE = 1

from module import *

Now suppose this code has been running correctly for a while. Then a
revision is made in module which adds the variable ERRORCODE to module.py
with a different value. Now suddenly the value of ERRORCODE is different in
your program which may lead to subtle bugs.

You may think this can be avoided by putting all import statements first in
your program before defining any variables (or classes, functions, etc).
But then you can have the same interaction between the different modules.

from graphics import *
from statistics import *

Now statistics can `shadow' a variable from graphics, for example if the
both have a function 'draw'. 
Of course the same could happen if you write:

from graphics import paint, draw
from statistics import draw, average

but at least then it is visible in your code.

And the most secure would be to use import graphics, and then use
graphics.draw etc.
-- 
Piet van Oostrum <piet at cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet at vanoostrum.org