Greg Ewing schrieb:
> Martin v. Löwis wrote:
>
>> a) the directory cache is out of date, and you should
>>re-read the directory
>> b) the module still isn't there, but is available in
>>a later directory on sys.path (which hasn't yet
>>been visited)
>> c) the module isn't there at all,
Martin v. Löwis wrote:
> a) the directory cache is out of date, and you should
>re-read the directory
> b) the module still isn't there, but is available in
>a later directory on sys.path (which hasn't yet
>been visited)
> c) the module isn't there at all, and the import will
>even
Greg Ewing schrieb:
> One thing I should add is that if you try to import
> a module that wasn't there before, the interpreter will
> notice this and has the opportunity to update its idea
> of what's on the disk.
How will it notice that it wasn't there before? The
interpreter will see that it has
Martin v. Löwis wrote:
> Currently, you can put a file on disk and import it
> immediately; that will stop working.
One thing I should add is that if you try to import
a module that wasn't there before, the interpreter will
notice this and has the opportunity to update its idea
of what's on the d
On Mon, 6 Nov 2006, Armin Rigo wrote:
> I know it's a discussion that comes up and dies out regularly. My two
> cents is that it would be saner to have two separate concepts: cache
> files used internally by the interpreter for speed reasons only, and
> bytecode files that can be shipped and impor
Delaney, Timothy (Tim) wrote:
> Would it be reasonable to always do a stat() on the directory,
> reloading if there's been a change? Would this be reliable across
> platforms?
To detect a new shadowing you'd have to stat all the
directories along sys.path, not just the one you think
the file is
Armin Rigo wrote:
It would seem good practice to remove all .pycs
after checking out a new version of the source,
just in case there are other problems such as
mismatched timestamps, which can cause the same
trouble.
> My two
> cents is that it would be saner to have two separate concepts: cache
On 7Nov 2006, at 12:20 AM, Greg Ewing wrote:
Also, if we do our own directory caching, the question
is when to invalidate the cache.
I think I'd be happy with having to do that explicitly.
I expect the vast majority of Python programs don't
need to track changes to the set of importable mo
"Martin v. Löwis" wrote:
> Greg Ewing schrieb:
>> I think I'd be happy with having to do that explicitly.
>> I expect the vast majority of Python programs don't
>> need to track changes to the set of importable modules
>> during execution. The exceptions would be things like
>> IDEs, and they coul
Greg Ewing schrieb:
> I think I'd be happy with having to do that explicitly.
> I expect the vast majority of Python programs don't
> need to track changes to the set of importable modules
> during execution. The exceptions would be things like
> IDEs, and they could do a cache flush before reloadi
On Tue, 07 Nov 2006 12:20:00 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>I think I'd be happy with having to do that explicitly.
>I expect the vast majority of Python programs don't
>need to track changes to the set of importable modules
>during execution. The exceptions would be things like
>I
Martin v. Löwis wrote:
> A stat call will not only look at the directory entry, but also
> look at the inode. This will require another disk access, as the
> inode is at a different location of the disk.
That should be in favour of the directory-reading
approach, since e.g. to find out which if a
On 11/6/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:>> Why not only import *.pyc files and no longer use *.pyo files. It is simpler to have one compiled python file extension.>> PYC files can contain optimized python byte code and normal byte
>> code.>> So what would you
Martin v. Löwis wrote:
>> Why not only import *.pyc files and no longer use *.pyo files.
>>
>> It is simpler to have one compiled python file extension.
>> PYC files can contain optimized python byte code and normal byte
>> code.
>
> So what would you do with the -O option of the interpreter?
I j
Armin Rigo wrote:
> Typical example: someone in the project removes a .py file, and checks
> in this change; someone else does an 'svn up', which kills the .py in
> his working copy, but not the .pyc. These stale .pyc's cause pain,
> e.g.
> by shadowing the real module (further down sys.path), or
Wolfgang Langner schrieb:
> Why not only import *.pyc files and no longer use *.pyo files.
>
> It is simpler to have one compiled python file extension.
> PYC files can contain optimized python byte code and normal byte code.
So what would you do with the -O option of the interpreter?
Regards,
M
Armin Rigo schrieb:
> My strong opinion on the matter is that importing a .pyc file if the .py
> file is not present is wrong in the first place.
There is, of course, an important use case (which you are addressing
with a different approach): people want to ship only byte code, not
source code, be
Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
> On Sat, Nov 04, 2006 at 04:47:37PM +0100, "Martin v. L?wis" wrote:
> > Patch #1346572 proposes to also search for .pyc when OptimizeFlag
> > is set, and for .pyo when it is not set. The author argues this is
> > for consistency, as the zipimport
Hi Martin,
On Sat, Nov 04, 2006 at 04:47:37PM +0100, "Martin v. L?wis" wrote:
> Patch #1346572 proposes to also search for .pyc when OptimizeFlag
> is set, and for .pyo when it is not set. The author argues this is
> for consistency, as the zipimporter already does that.
My strong opinion on the
Why not only import *.pyc files and no longer use *.pyo files.
It is simpler to have one compiled python file extension.
PYC files can contain optimized python byte code and normal byte code.
--
bye by Wolfgang
___
Python-Dev mailing list
Python-Dev@p
Greg Ewing schrieb:
>> That should never be better: the system will cache the directory
>> blocks, also, and it will do a better job than Python will.
>
> If that's really the case, then why do discussions
> of how improve Python startup speeds seem to focus
> on the number of stat calls made?
A
Martin v. Löwis wrote:
> That should never be better: the system will cache the directory
> blocks, also, and it will do a better job than Python will.
If that's really the case, then why do discussions
of how improve Python startup speeds seem to focus
on the number of stat calls made?
Also, ca
Aahz schrieb:
> Maybe so, but I recently dealt with a painful bottleneck in Python code
> caused by excessive stat() calls on a directory with thousands of files,
> while the os.listdir() function was bogging things down hardly at all.
> Granted, Python bytecode was almost certainly the cause of mu
On 11/5/06, Steve Holden <[EMAIL PROTECTED]> wrote:
[Off-list]Brett Cannon wrote:[...]>> Hopefully my import rewrite is flexible enough that people will be able> to plug in their own importer/loader for the filesystem so that they can> tune how things like this are handled (
e.g., caching what file
On Sun, Nov 05, 2006, "Martin v. L?wis" wrote:
> Greg Ewing schrieb:
>> Fredrik Lundh wrote:
>>>
>>> well, from a performance perspective, it would be nice if Python looked
>>> for *fewer* things, not more things.
>>
>> Instead of searching for things by doing a stat call for each
>> possible fi
[Off-list]
Brett Cannon wrote:
[...]
>
> Hopefully my import rewrite is flexible enough that people will be able
> to plug in their own importer/loader for the filesystem so that they can
> tune how things like this are handled (e.g., caching what files are in a
> directory, skipping bytecode f
On 11/4/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
On Sun, 05 Nov 2006 14:21:34 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:>Fredrik Lundh wrote:>>> well, from a performance perspective, it would be nice if Python looked
>> for *fewer* things, not more things.>>Instead of searching for thin
Greg Ewing schrieb:
> Fredrik Lundh wrote:
>
>> well, from a performance perspective, it would be nice if Python looked
>> for *fewer* things, not more things.
>
> Instead of searching for things by doing a stat call
> for each possible file name, would it perhaps be
> faster to read the content
On Sun, 05 Nov 2006 14:21:34 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Fredrik Lundh wrote:
>
>> well, from a performance perspective, it would be nice if Python looked
>> for *fewer* things, not more things.
>
>Instead of searching for things by doing a stat call
>for each possible file name,
Fredrik Lundh wrote:
> well, from a performance perspective, it would be nice if Python looked
> for *fewer* things, not more things.
Instead of searching for things by doing a stat call
for each possible file name, would it perhaps be
faster to read the contents of all the directories
along sys
On 11/4/06, Osvaldo Santana <[EMAIL PROTECTED]> wrote:
Hi,I'm the author of this patch and we are already using it in Pythonport for Maemo platform.We are using .pyo modules mainly to remove docstrings from themodules. We've discussed about this patch here[1] before.
Now, I agree that the zipimport
On 11/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Fredrik Lundh schrieb:>> However, I find the proposed behaviour reasonable: Python already>> automatically imports the .pyc file if .py is not given and vice>> versa. So why not look for .pyo if the .pyc file is not present?
>> well, from a p
Hi,
I'm the author of this patch and we are already using it in Python
port for Maemo platform.
We are using .pyo modules mainly to remove docstrings from the
modules. We've discussed about this patch here[1] before.
Now, I agree that the zipimport behaviour is incorrect but I don't
have other o
Fredrik Lundh schrieb:
>> However, I find the proposed behaviour reasonable: Python already
>> automatically imports the .pyc file if .py is not given and vice
>> versa. So why not look for .pyo if the .pyc file is not present?
>
> well, from a performance perspective, it would be nice if Python l
Martin v. Löwis wrote:
> However, I find the proposed behaviour reasonable: Python already
> automatically imports the .pyc file if .py is not given and vice
> versa. So why not look for .pyo if the .pyc file is not present?
well, from a performance perspective, it would be nice if Python looked
On Sat, Nov 04, 2006 at 04:47:37PM +0100, "Martin v. L?wis" wrote:
> Patch #1346572 proposes to also search for .pyc when OptimizeFlag
> is set, and for .pyo when it is not set. The author argues this is
> for consistency, as the zipimporter already does that.
>
> This reasoning is somewhat flawed
Patch #1346572 proposes to also search for .pyc when OptimizeFlag
is set, and for .pyo when it is not set. The author argues this is
for consistency, as the zipimporter already does that.
This reasoning is somewhat flawed, of course: to achieve consistency,
one could also change the zipimporter in
37 matches
Mail list logo
