Hi Guido,
On Thu, Sep 21, 2006 at 07:22:04AM -0700, Guido van Rossum wrote:
sys.path exists to stitch together the toplevel module/package
namespace from diverse sources.
Import hooks and sys.path hackery exist so that module/package sources
don't have to be restricted to the filesystem (as
Armin Rigo wrote:
This doesn't match my experience, which is that sys.path hackery is
required in any project that is larger than one directory, but is not
itself a library. [...]
myapp/
main.py
a/
__init__.py
b.py
test_b.py
c/
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python 2.5). There can be a system-wide database that all
Brett Cannon wrote:
But either way I will be messing with the import system in the
relatively near future. If you want to help, Paul (or anyone else),
just send me an email and we can try to coordinate something (plan to do
the work in the sandbox as a separate thing from my security
At 12:08 AM 9/22/2006 -0700, Josiah Carlson wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:08 AM 9/22/2006 -0700, Josiah Carlson wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
[snip]
You misunderstood me: I mean that the per-user database must be able to
store information for
At 12:42 PM 9/22/2006 -0700, Josiah Carlson wrote:
You might as well suggest that each environment
consist of a single large zipfile containing the packages in question:
this
would actually be *more* practical (and fast!) in terms of Python startup,
and is no different from having a
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:42 PM 9/22/2006 -0700, Josiah Carlson wrote:
[snip]
Measure it. Be sure to include the time to import SQLite vs. the time to
import the zipimport module.
[snip]
Again, seriously, compare this against a zipfile. You'll find that there's
Guido van Rossum wrote:
On 9/19/06, Greg Ewing [EMAIL PROTECTED] wrote:
I haven't really thought it through in detail. It
just seems as though it would be a lot less confusing
if you could figure out from static information which
module will get imported by a given import statement,
instead of
Oleg Broytmann wrote:
There really shouldn't be
any such thing as sys.path -- the view that any
given module has of the package namespace should
depend only on where it is
I do not understand this. Can you show an example? Imagine I have
two servers, Linux and FreeBSD, and on Linux
On 9/21/06, Giovanni Bajo [EMAIL PROTECTED] wrote:
Greg Eqing wrote:
There really shouldn't be
any such thing as sys.path -- the view that any
given module has of the package namespace should
depend only on where it is
My idea (and interpretation of Greg's statement) is that a
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I think one missing feature is a mechanism whereby you can say THIS
package (gives top-level package name) lives HERE (gives filesystem
location of package) without adding the parent of HERE to sys.path
for all module searches. I think
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/21/06, Paul Moore [EMAIL PROTECTED] wrote:
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I think one missing feature is a mechanism whereby you can say THIS
package (gives top-level package name) lives HERE (gives filesystem
At 01:54 PM 9/21/2006 -0700, Guido van Rossum wrote:
On 9/21/06, Paul Moore [EMAIL PROTECTED] wrote:
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I think one missing feature is a mechanism whereby you can say THIS
package (gives top-level package name) lives HERE (gives filesystem
On 9/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Isn't the main problem how to specify a bunch of these in the
environment?
Yes, that's exactly the problem, assuming that by environment you mean the
operating environment, as opposed to e.g. os.environ.
Hmm, now I don't understand again.
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/21/06, Paul Moore [EMAIL PROTECTED] wrote:[SNIP] Hmm, I might play with this - a set of PEP 302 importers to completely customise the import mechanism. The never-completed phase 2 of the
PEP included a reimplementation of the built in
On 9/21/06, Paul Moore [EMAIL PROTECTED] wrote:
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Isn't the main problem how to specify a bunch of these in the
environment? Or can this be done through .pkg files? Those aren't
cheap either though -- it would be best if the work was only
Guido van Rossum wrote:
Eek? If there are two third-party top-level packages A and B, by
different third parties, and A depends on B, how should A find B if
not via sys.path or something that is sufficiently equivalent as to
have the same problems?
Some kind of configuration mechanism is
Another thought on static module namespace configuration:
It would make things a *lot* easier for py2exe, py2app
and the like that have to figure out what packages
a program depends on without running the program.
--
Greg
___
Python-Dev mailing list
At 12:07 PM 9/22/2006 +1200, Greg Ewing wrote:
Another thought on static module namespace configuration:
It would make things a *lot* easier for py2exe, py2app
and the like that have to figure out what packages
a program depends on without running the program.
Setuptools users already explicitly
On 9/21/06, Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Eek? If there are two third-party top-level packages A and B, by
different third parties, and A depends on B, how should A find B if
not via sys.path or something that is sufficiently equivalent as to
have the same
Giovanni Bajo wrote:
My idea (and interpretation of Greg's statement) is that a module/package
should be able to live with either relative imports within itself, or fully
absolute imports.
I think it goes further than that -- each module should
(potentially) have its own unique view of the
On 9/21/06, Greg Ewing [EMAIL PROTECTED] wrote:
Giovanni Bajo wrote:
My idea (and interpretation of Greg's statement) is that a module/package
should be able to live with either relative imports within itself, or fully
absolute imports.
I think it goes further than that -- each module
Guido van Rossum wrote:
While I agree with your idea(l), I don't think that's what Greg meant.
He clearly say sys.path should not exist at all.
Refining that a bit, I don't think there should be
a *single* sys.path for the whole program -- more
like each module having its own sys.path. And, at
Guido van Rossum wrote:
On 9/21/06, Greg Ewing [EMAIL PROTECTED] wrote:
I think it goes further than that -- each module should
(potentially) have its own unique view of the module
namespace, defined at the time the module is installed,
that can't be disturbed by anything that any other
Guido writes:
As Phillip understood, I meant the environment to include the
filesystem (and on Windows, the registry -- in fact, Python on Windows
*has* exactly such a mechanism in the registry, although I believe
it's rarely used these days -- it was done by Mark Hammond to support
COM
Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Eek? If there are two third-party top-level packages A and B, by
different third parties, and A depends on B, how should A find B if
not via sys.path or something that is sufficiently equivalent as to
have the same problems?
At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python 2.5). There can be a system-wide database that all users use as
a base, with a user-defined package
Paul Moore wrote:
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I think one missing feature is a mechanism whereby you can say THIS
package (gives top-level package name) lives HERE (gives filesystem
location of package) without adding the parent of HERE to sys.path
for all module
On 9/19/06, Greg Ewing [EMAIL PROTECTED] wrote:
I haven't really thought it through in detail. It
just seems as though it would be a lot less confusing
if you could figure out from static information which
module will get imported by a given import statement,
instead of having it depend on
On Tue, Sep 19, 2006 at 03:46:59PM +1200, Greg Ewing wrote:
There really shouldn't be
any such thing as sys.path -- the view that any
given module has of the package namespace should
depend only on where it is
I do not understand this. Can you show an example? Imagine I have two
servers,
Josiah Carlson wrote:
As it stands, in order to work around this particular feature, one
would need to write a 'loader' to handle importing and/or main() calling
in subpackage1/module1.py .
Yup. At the moment, you can rely on PEP 328, or an PEP 338, but not both at
the same time. This was
Greg Ewing wrote:
Armin Rigo wrote:
My (limited) understanding of the motivation for relative imports is
that they are only here as a transitional feature. Fully-absolute
imports are the official future.
Guido does seem to have a dislike for relative imports,
but I don't really
Steve Holden wrote:
This does, of course, assume that you're importing modules from the
filestore, which assumption is no longer valid in the presence of PEP
302 importers.
Well, you need to allow for a sufficiently abstract
notion of filesystem.
I haven't really thought it through in
Greg Ewing wrote:
Steve Holden wrote:
This does, of course, assume that you're importing modules from the
filestore, which assumption is no longer valid in the presence of PEP
302 importers.
Well, you need to allow for a sufficiently abstract
notion of filesystem.
For some value of
Hi Fabio,
On Sun, Sep 17, 2006 at 03:38:42PM -0300, Fabio Zadrozny wrote:
I've been playing with the new features and there's one thing about
the new relative import that I find a little strange and I'm not sure
this was intended...
My (limited) understanding of the motivation for relative
Fabio Zadrozny wrote:
I've been playing with the new features and there's one thing about
the new relative import that I find a little strange and I'm not sure
this was intended...
When you do a from . import xxx, it will always fail if you're in a
top-level module, and when executing any
Armin Rigo wrote:
My (limited) understanding of the motivation for relative imports is
that they are only here as a transitional feature. Fully-absolute
imports are the official future.
Guido does seem to have a dislike for relative imports,
but I don't really understand why. The usefulness
Greg Ewing [EMAIL PROTECTED] wrote:
Armin Rigo wrote:
there
is no clean way from a test module 'foo.bar.test.test_hello' to import
'foo.bar.hello': the top-level directory must first be inserted into
sys.path magically.
I've felt for a long time that problems like this
wouldn't arise
On 9/18/06, Greg Ewing [EMAIL PROTECTED] wrote:
Armin Rigo wrote: My (limited) understanding of the motivation for relative imports is that they are only here as a transitional feature.Fully-absolute imports are the official future.
Guido does seem to have a dislike for relative imports,but I
I've been playing with the new features and there's one thing about
the new relative import that I find a little strange and I'm not sure
this was intended...
When you do a from . import xxx, it will always fail if you're in a
top-level module, and when executing any module, the directory of the
41 matches
Mail list logo
