En Fri, 22 Aug 2008 17:31:58 -0300, Medardo Rodriguez (Merchise Group) <[EMAIL
PROTECTED]> escribió:
> On Fri, Aug 22, 2008 at 1:25 PM, Gabriel Genellina
> <[EMAIL PROTECTED]> wrote:
>> what if __init__.py contains code?
>
> Thats what I usually do to solve the "problem", but for my taste it's
> better to write the test code of a module inside it.
> The code I write in "__init__.py" is related to structures of
> initializations, globals at package level.
>
> if __name__ == "__main__":
> pass # Here I test only concepts related to the entire package,
> not to any module.
I think you misunderstood the comment.
Suppose this setup:
SomeDir/
SomePackage/
__init__.py
module1.py
module2.py
test.py
When someone executes test.py directly, currently Python doesn't know that it
is contained inside a package, and some forms of relative imports don't work.
To make relative imports work, Python should be aware that test.py is contained
inside a package. Looking for an __init__.py file at the same directory may
reveal that there is a package - but that's not enough, because when a package
is actually imported, its __init__.py is executed and a new module object is
placed in sys.modules.
So, when test.py is run directly, what to do with the code in __init__.py?
should it be executed, and when? I don't know the actual reasons, but this
seems enough trouble to me to NOT automatically recognize a package unless
someone actually imports it.
The application will import the package anyway, so why would the test code not
do the same thing? I want to mimic the production environment as closely as
possible in the testing environment. And the easiest way to do that is to
"import SomePackage" in a script placed at SomeDir. The actual tests may reside
in test.py, of course, but now Python *knows* that test.py lives inside a
package and relative imports work fine now.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
