Gabriel Genellina wrote:
En Thu, 20 Nov 2008 17:36:11 -0200, Stef Mientki
<[EMAIL PROTECTED]> escribió:
I'm not an expert, I even don't fully understand your problem,
but having struggled with imports in the past,
I've a solution now, which seems to work quit well.
That's not very helpful, is it? Were you planning to keep the solution
secret?
sorry slip of the keyboard ;-)
http://mientki.ruhosting.nl/data_www/pylab_works/pw_importing.html
May I reiterate my criticism to your "solution" posted last week?
You're welcome,
if there are better (even more important simpler) solutions, I'm in.
I don't think extending sys.path to include every directory under your
project is a good idea. Basically, you're flattening the directory
layout, removing any structure, like it was before Python 1.5 added
package support.
It is like dumping all your modules in a single directory, with no
hierarchy and lots of name conflicts.
Well I started at 2.4 and now arrived at 2.5, so I don't know what it
was at 1.5.
And I'm probably going to stay at 2.5 for a long time, upgrading is one
of the few (maybe the only) disadvantages of Python ;-)
For Python, I guess you're right, all files are in one flat directory, ...
... but it's just 1 program, so what's the objection ?
For the program itself, which is highly dynamic, it can find sets of
python-files in certain subpaths,
so that's quit ordered I think ?
Worse: because your proposal makes the same file reachable under many
different names, the *same* source module will generate *different*
module objects stored as *different* entries in sys.modules. Globals
don't work anymore, subclasses aren't subclasses... lots of problems.
Could you explain this a little more ...
... I'm just adding every subpath to the Pythonpath,
so in my ignorant believe, every module is imported the same way, but I
might be wrong.
" Globals not working" , a good program doesn't have any globals ( said
a non-programmer ;-)
Subclasses aren't subclasses ? ( I always derive subclasses in the
module itself, or in the same directory as the parentclass)
Relative imports (PEP328 [1]) were introduced -among other things- as
an attempt to avoid such problems. You're going in the opposite
direction. Please stop doing that - or at least keep us informed of
where you work!
[1] http://www.python.org/dev/peps/pep-0328
Sorry I don't understand all that pep-talk (I'm not a programmer ;-)
I read it starts with " For the second problem, it is proposed that all
import statements be absolute by default (searching sys.path only) with
special syntax (leading dots) for accessing package-relative imports."
I think that's exactly what I'm doing: absolute imports.
Please explain in simple language what I'm all doing wrong,
or how I get a better solution.
thanks,
Stef
--
http://mail.python.org/mailman/listinfo/python-list
