Re: Two import questions in Python 3.0
On 24 Jan., 18:51, Scott David Daniels wrote: > Kay Schluehr wrote: > > On 24 Jan., 09:21, "Gabriel Genellina" wrote: > >> If you run A.py as a script, it does not "know" it lives inside a package. > >> You must *import* A for it to become aware of the package. > >> Also, the directory containing the script comes earlier than PYTHONPATH > >> entries in sys.path -- so watch for that case too. > > Thanks, yes. I always make the same error thinking that a directory > > with the ritual __init__ file is actually a package ( as some kind of > > platonic entity ), something that is more obvious to me than it is to > > the runtime. The relative import semantics introduced with Python 2.5 > > has made the error just visible that was hidden to me for about a > > decade. Shit. > > Temper the language a bit. You lose your effectiveness by some people > reading the color of your words, rather than their meaning in code. Sigh, yes... sorry. I'm just too frustrated. Actually I don't even know why the import machinery is such a mess and I don't want to spend a huge amount of time ( like Brett Cannon ) to figure it out. I'll spent a few hours of time writing a script that turns all relative paths into absolute ones without changing the source otherwise. Then I'm at least done with that and won't ever see the "relative import in non-packages" exceptions anymore in any code I touch ( I can also ignore __package__, -m and all the other workarounds ). It's not the first time Python is in my way but this time it hurts. -- http://mail.python.org/mailman/listinfo/python-list
Re: Two import questions in Python 3.0
Kay Schluehr wrote:
On 24 Jan., 09:21, "Gabriel Genellina" wrote:
If you run A.py as a script, it does not "know" it lives inside a package.
You must *import* A for it to become aware of the package.
Also, the directory containing the script comes earlier than PYTHONPATH
entries in sys.path -- so watch for that case too.
Thanks, yes. I always make the same error thinking that a directory
with the ritual __init__ file is actually a package ( as some kind of
platonic entity ), something that is more obvious to me than it is to
the runtime. The relative import semantics introduced with Python 2.5
has made the error just visible that was hidden to me for about a
decade. Shit.
Temper the language a bit. You lose your effectiveness by some people
reading the color of your words, rather than their meaning in code.
By the way, if you run the script as:
$ python -m package.A
You may get what you want
demo (language fixed up a bit, moe info printed):
in .../lib/site-packages:
possible.py
-
print('import from top possible: %s' % __file__)
in .../lib/site-packages/package:
possible.py
-
print('import from package.possible: %s' % __file__)
__init__.py
-
print('package initialized: %s' % __file__)
A.py
--
print('A started: %s' % __file__)
import possible
print('A running: %s' % __file__)
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: Two import questions in Python 3.0
On 24 Jan., 09:21, "Gabriel Genellina" wrote: > If you run A.py as a script, it does not "know" it lives inside a package. > You must *import* A for it to become aware of the package. > Also, the directory containing the script comes earlier than PYTHONPATH > entries in sys.path -- so watch for that case too. Thanks, yes. I always make the same error thinking that a directory with the ritual __init__ file is actually a package ( as some kind of platonic entity ), something that is more obvious to me than it is to the runtime. The relative import semantics introduced with Python 2.5 has made the error just visible that was hidden to me for about a decade. Shit. -- http://mail.python.org/mailman/listinfo/python-list
Re: Two import questions in Python 3.0
En Sat, 24 Jan 2009 05:24:15 -0200, Kay Schluehr
escribió:
1. I'd expected that absolute imports are used in Python 3.0 by
default. I may be wrong. I've written two versions of a module
sucks.py
sucks.py
-
print ("import from lib.sucks")
sucks.py
-
print ("import from package.sucks")
The first is placed in the lib directory that is globally visible by
means of PYTHONPATH. The second one is placed in a package
package/
__init__.py
sucks.py
A.py
The package also contains a module A.py defined by
A.py
--
import sucks
Running A yields "import from package.sucks" which means unconditional
relative import. It shadows the globally visible sucks.py module. I've
expected it the other way round.
If you run A.py as a script, it does not "know" it lives inside a package.
You must *import* A for it to become aware of the package.
Also, the directory containing the script comes earlier than PYTHONPATH
entries in sys.path -- so watch for that case too.
python test_parser.py
Traceback (most recent call last):
File "test_parser.py", line 12, in
from . import support
ValueError: Attempted relative import in non-package
The standard error of the years to come that makes working with Python
harder and reminds me that it is not a scripting language anymore
because you can't run anything as a script not even a test.
I always consider that packages are libraries. Application code "uses" a
library (by importing things from it). Test code should mimic closely that
behavior: my tests always import the package, like the application would
do.
Anyway I should revisit the strategy, I've not evaluated yet how much is
affected by absolute imports and other changes in 3.0
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Two import questions in Python 3.0
1. I'd expected that absolute imports are used in Python 3.0 by
default. I may be wrong. I've written two versions of a module
sucks.py
sucks.py
-
print ("import from lib.sucks")
sucks.py
-
print ("import from package.sucks")
The first is placed in the lib directory that is globally visible by
means of PYTHONPATH. The second one is placed in a package
package/
__init__.py
sucks.py
A.py
The package also contains a module A.py defined by
A.py
--
import sucks
Running A yields "import from package.sucks" which means unconditional
relative import. It shadows the globally visible sucks.py module. I've
expected it the other way round.
2. This is kind of a change request.
In a former life I used to call test-scripts as test-scripts. The dumb
idea was to point e.g. to
lib/tests and run
python test_ast.py
test_nodeclasses (__main__.AST_Tests) ... ok
test_parse (__main__.ASTHelpers_Test) ... ok
--
Ran 12 tests in 0.219s
OK
The new style is implemented rather in lib2to3. If I point to lib/
lib2to3/tests and run
python test_parser.py
Traceback (most recent call last):
File "test_parser.py", line 12, in
from . import support
ValueError: Attempted relative import in non-package
The standard error of the years to come that makes working with Python
harder and reminds me that it is not a scripting language anymore
because you can't run anything as a script not even a test.
For pedagogical reasons the behavior of test_ast.py and other standard
library tests shall show uniform behavior when called from the command
line i.e. they shall all fail with this import error message. What do
you think?
--
http://mail.python.org/mailman/listinfo/python-list
