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/
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
"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
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 havin
"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 informa
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 shipp
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 st
"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
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
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 pack
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 sa
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
At 12:40 PM 9/22/2006 +1200, Greg Ewing wrote:
>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 progra
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 o
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,
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 -- eac
I think it would be worth writing up a PEP to describe this, if it's
to become a de-facto standard. That might be a better path towards
standardization than just checking in the code... :-/
--Guido
On 9/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:07 PM 9/22/2006 +1200, Greg Ewing wro
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:
> 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
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 explicit
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
Pyth
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
At 03:28 PM 9/21/2006 -0700, Guido van Rossum wrote:
>os.environ is useless because there's no way for a package installer
>to set it for all users.
Or even for *one* user! :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
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
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 buil
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
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 (giv
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
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
> > location of package)" without adding the p
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 thi
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) i
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
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,
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
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
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:
> 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 re
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
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
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
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
> w
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 usefulnes
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
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
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
m
45 matches
Mail list logo
