Creating classes and objects more than once?

[Gabriel Genellina]

En Sat, 29 Nov 2008 04:51:59 -0200, Carl Banks <pavlovevidence at gmail.com>  
escribió:
> On Nov 28, 11:51 pm, Carl Banks

>> Absolute versus relative imports don't have anything to do with the
>> issue here.  PEP 328 concerns itself with imports relative to the
>> executing module in package space.  It has nothing to do with imports
>> relative to the current directory in filename space.
>
>
> I thought of another way to put this to help explain things.  Suppose
> you have two files in your current directory, a Python script file
> (app.py) which imports a Python module (work.py).
>
> Near the top of the file app.py, there is line like this:
>
> import work
>
> What happens beneath the covers when this statement is excuted (and
> from __future__ import absolute_import hasn't been run)?  Many people
> seem to think that the Python interpreter first considers whether this
> is a relative import and starts by looking for "sister" modules in the
> same "package" (i.e., directory).  Python would thus see the file
> work.py in the same "package" and complete this as a relative import.
>
> Thus, they reason, if one were to add "from __future__ import
> absolute_import" to the top of app.py, the import would no longer work
> because implicit relative imports have been disabled.  One would have
> to use "from . import work" instead.
>
> Well, this is not how it happens.  No top level module, including
> __main__, is in a package.  Thus, when Python sees "import work" in a
> top-level module, it doesn't consider it to be a relative import, even
> when implicit relative imports have not been disabled.
>
> The point of this is, disabling implicit relative imports has no
> effect on imports from top-level modules since they were never
> relative imports anyway.  Python is able to find the "sisters" of top-
> level modules and scripts not because it is doing a relative import,
> but because those "sister" modules are in one of the directories
> listed in sys.path.
>
> In particular, if "" is listed in sys.path, the current working
> directory--even when modified by os.chdir--will be searched for
> "sisters" of top-level modules.

While all the above explanation is true for scripts executed using "python  
xxx.py", it's not the same when you execute a module using runpy.py, that  
is, using "python -m xxx"
If you execute a module inside a package in that way, Python recognizes  
the fact it's inside a package, and honors relative imports (starting from  
version 2.6, when PEP366 was implemented).
So the statement "from __future__ import absolute_import" *does* change  
how imports are handled on the top module.
A simple test showing the difference:

C:\temp\test366>dir /b
b.py
pkga

C:\temp\test366>type b.py
msg='this is the external b module'

C:\temp\test366>cd pkga

C:\temp\test366\pkga>dir /b
abs.py
b.py
rel.py
__init__.py

C:\temp\test366\pkga>type __init__.py

C:\temp\test366\pkga>type b.py
msg='this is the b module inside package pkga'

C:\temp\test366\pkga>type rel.py
print "this script uses 'traditional' import semantics"
 from b import msg
print msg
print "using a bare import:"
import b
print b.msg

C:\temp\test366\pkga>type abs.py
 from __future__ import absolute_import
print "this script sets absolute_import"
print "using an absolute import:"
 from b import msg
print msg
print "using a bare import:"
import b
print b.msg
print "using an explicit relative import:"
 from .b import msg
print msg

C:\temp\test366\pkga>cd ..

C:\temp\test366>python -m pkga.rel
this script uses 'traditional' import semantics
this is the b module inside package pkga
using a bare import:
this is the b module inside package pkga

C:\temp\test366>python -m pkga.abs
this script sets absolute_import
using an absolute import:
this is the external b module
using a bare import:
this is the external b module
using an explicit relative import:
this is the b module inside package pkga

-- 
Gabriel Genellina