[Sndobj-devel] Fwd: importing namespaces/modules 1of3

[sonify <so...@av...>]

Begin forwarded message:

> From: Piet van Oostrum <pi...@cs...>
> Date: 19 January 2007 8:27:39 PM
> To: David Worrall <vi...@av...>
> Cc: Pyt...@py...
> Subject: Re: [Pythonmac-SIG] importing namespaces/modules
>
>>>>>> David Worrall <vi...@av...> (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 <pi...@cs...>
> URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
> Private email: pi...@va...
>

_____________________________
David Worrall: so...@av...