Martin v. Löwis wrote:
> Scott David Daniels wrote:
>
Is the interpreter unable to call "C" functions ("stat" for example)
to determine whether an object exists before it puts it on "path".
>>>
>>>
>>>What do you mean, "unable to"? It just doesn't.
>>
>>In fact, the interpreter doesn't nec
Dieter Maurer wrote:
> Steve Holden <[EMAIL PROTECTED]> writes on Sun, 22 May 2005 16:19:10 -0400:
>
>>...
>>Indeed I have written PEP 302-based code to import from a relational
>>database, but I still don't believe there's any satisfactory way to
>>have [such a hooked import mechanism] be a first
Scott David Daniels <[EMAIL PROTECTED]> writes on Wed, 25 May 2005 07:10:00
-0700:
> ...
> I'll bet this means that the 'zope.zip', 'python24.zip' would drop
> you to "about 12500 - 1 = 2500" failing opens. That should be
> an easy test: sys.path.insert(0, 'zope.zip') or whatever.
> If that w
"Martin v. Löwis" <[EMAIL PROTECTED]> writes on Tue, 24 May 2005 23:58:03 +0200:
> ... 10.000 failing opens -- a cause for significant IO during startup ? ...
> So I would agree that IO makes a significant part of startup, but
> I doubt it is directory reading (unless perhaps you have an
> absent
Dieter Maurer wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> writes on Sun, 22 May 2005 21:24:41
> +0200:
>>...
>>>The application was Zope importing about 2.500 modules
>>>from 2 zip files "zope.zip" and "python24.zip".
>>>This resulted in about 12.500 opens -- about 4 times more
>>>than would be
Dieter Maurer wrote:
> The comparison between warm start (few disc io) and cold start
> (much disc io) tells you that the import process is highly
> io dominated (for cold starts).
Correct. However, I would expect that the contents of existing
directories is cached, and it might be that the absenc
"Martin v. Löwis" <[EMAIL PROTECTED]> writes on Sun, 22 May 2005 21:24:41 +0200:
> ...
> What do you mean, "unable to"? It just doesn't.
The original question was: "why does Python put non-existing
entries on 'sys.path'".
Your answer seems to be: "it just does not do it -- but it might
be changed
Steve Holden <[EMAIL PROTECTED]> writes on Sun, 22 May 2005 16:19:10 -0400:
> ...
> Indeed I have written PEP 302-based code to import from a relational
> database, but I still don't believe there's any satisfactory way to
> have [such a hooked import mechanism] be a first-class component of an
> a
Robin Becker wrote:
> if the importers are tested statically how does a filesystem path ever
> manage
> to get back into the loop if it was ever found missing? In other words if
> things (eg python24.zip) are found not importable/usable in one pass how do
> they get reinstated?
I think (but see t
Martin v. Löwis wrote:
> Robin Becker wrote:
>
>>ie if we have N importers and F leading failure syspath entries before
>>the correct one is found do we get order N*F failed stats/opens etc etc?
>
>
> No. Each path hook is supposed to provide a decision as to whether this
> is a useful item on s
Robin Becker wrote:
> ie if we have N importers and F leading failure syspath entries before
> the correct one is found do we get order N*F failed stats/opens etc etc?
No. Each path hook is supposed to provide a decision as to whether this
is a useful item on sys.path only once; the importer objec
Martin v. Löwis wrote:
>
>
> Now I remember what makes this stuff really difficult: PEP 302
> introduces path hooks (sys.path_hooks), allowing imports from
> other sources than files. So the items on sys.path don't have
> to be directory or file names at all, and importing from them
> may st
Scott David Daniels wrote:
>>> Is the interpreter unable to call "C" functions ("stat" for example)
>>> to determine whether an object exists before it puts it on "path".
>>
>>
>> What do you mean, "unable to"? It just doesn't.
>
> In fact, the interpreter doesn't necessarily know when it is
> aff
Martin v. Löwis wrote:
> Dieter Maurer wrote:
>
>>Really?
>>
>>Is the interpreter unable to call "C" functions ("stat" for example)
>>to determine whether an object exists before it puts it on "path".
>
> What do you mean, "unable to"? It just doesn't.
In fact, the interpreter doesn't necessarily
Dieter Maurer wrote:
> Steve Holden <[EMAIL PROTECTED]> writes on Sun, 22 May 2005 09:14:43 -0400:
>
>>...
>>There are some aspects of Python's initialization that are IMHO a bit
>>too filesystem-dependent. I mentioned one in
>>
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=111652
Dieter Maurer wrote:
> Really?
>
> Is the interpreter unable to call "C" functions ("stat" for example)
> to determine whether an object exists before it puts it on "path".
What do you mean, "unable to"? It just doesn't.
Could it? Perhaps, if somebody wrote a patch.
Would the patch be accepted?
Steve Holden <[EMAIL PROTECTED]> writes on Sun, 22 May 2005 09:14:43 -0400:
> ...
> There are some aspects of Python's initialization that are IMHO a bit
> too filesystem-dependent. I mentioned one in
>
>
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1116520&group_id=5470&atid=10
"Martin v. Löwis" <[EMAIL PROTECTED]> writes on Sat, 21 May 2005 23:53:31 +0200:
> Dieter Maurer wrote:
> ...
> > The question was:
> >
> >"should python start up with **non-existent** objects on the path".
> >
> > I think there is no reason why path needs to contain an object
> > which does
Robin Becker wrote:
> Dieter Maurer wrote:
[...]
>
> I think this was my intention, but also I think I have some concern over
> having two possible locations for the standard library. It seems non pythonic
> and liable to cause confusion if some package should manage to install
> python24.zip whil
Dieter Maurer wrote:
> The question was:
>
>"should python start up with **non-existent** objects on the path".
>
> I think there is no reason why path needs to contain an object
> which does not exist (at the time the interpreter starts).
There is. When the interpreter starts, it doesn't kn
Dieter Maurer wrote:
.
>
> The question was:
>
>"should python start up with **non-existent** objects on the path".
>
> I think there is no reason why path needs to contain an object
> which does not exist (at the time the interpreter starts).
>
> In your use case, "python24.zip" does e
"Martin v. Löwis" <[EMAIL PROTECTED]> writes on Fri, 20 May 2005 18:13:56 +0200:
> Robin Becker wrote:
> > Firstly should python start up with non-existent entries on the path?
>
> Yes, this is by design.
>
> > Secondly is this entry be the default for some other kind of python
> > installation?
Robin Becker wrote:
> Firstly should python start up with non-existent entries on the path?
Yes, this is by design.
> Secondly is this entry be the default for some other kind of python
> installation?
Yes. People can package everything they want in python24.zip (including
site.py). This can onl
23 matches
Mail list logo
