Mark Hammond schrieb:
release. The main reason why I changed the import behavior was
pythonservice.exe from the win32 extensions. pythonservice.exe imports
the module that contains the service class, but because
pythonservice.exe doesn't run in optimized mode, it will only import a
.py or a .pyc
Guido van Rossum schrieb:
On 11/11/05, Ulrich Berning [EMAIL PROTECTED] wrote:
For instance, nobody would give the output of a C compiler a different
extension when different compiler flags are used.
But the usage is completely different. With C you explicitly manage
when compilation
release. The main reason why I changed the import behavior was
pythonservice.exe from the win32 extensions. pythonservice.exe imports
the module that contains the service class, but because
pythonservice.exe doesn't run in optimized mode, it will only import a
.py or a .pyc file, not a .pyo
Phillip J. Eby schrieb:
At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
By the way, while we're on this subject, can we make the optimization
options be part of the compile() interface? Right now the distutils has to
actually
On 11/11/05, Ulrich Berning [EMAIL PROTECTED] wrote:
Guido, if it was intentional to separate slightly different generated
bytecode into different files and if you have good reasons for doing
this, why have I never seen a .pyoo file :-)
Because -OO was an afterthought and not implemented by
Paul Moore wrote:
On 11/9/05, Bob Ippolito [EMAIL PROTECTED] wrote:
On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP,
Nick Coghlan wrote:
Please consider looking at and commenting on PEP 328 - I got zero feedback
when I wrote it, and basically assumed no-one else was bothered by the -m
switch's fairly significant limitations (it went in close to the first Python
2.4 alpha release, so we wanted to keep it
On 11/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Paul Moore wrote:
On 11/9/05, Bob Ippolito [EMAIL PROTECTED] wrote:
On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1)
At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
By the way, while we're on this subject, can we make the optimization
options be part of the compile() interface? Right now the distutils has to
actually exec another Python process
On 11/10/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
By the way, while we're on this subject, can we make the optimization
options be part of the compile() interface? Right now the
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
You didn't show us what's in the zip file. Can you show a zipinfo output?
$ zipinfo modules.zip
Archive: modules.zip 426 bytes 2 files
-rw-r--r-- 2.3 unx 109 bx defN 31-Oct-05 14:49 module_o.pyo
-rw-r--r-- 2.3 unx 109 bx
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
Unless others are interested in this nothing will happen.
I've never heard of a third party making their code available only as
.pyo,
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
That would not be enough, because it would leave the docstrings in the .pyc
files.
Unless others are interested in this nothing
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
I agree with this idea, but we've to think about docstrings (like
Nicola said
On 11/9/05, Osvaldo Santana [EMAIL PROTECTED] wrote:
I've noticed this inconsistency when we stop to use zipimport in our
Python For Maemo distribution. We've decided to stop using zipimport
because the device (Nokia 770) uses a compressed filesystem.
I won't comment further on the brainstorm
At 11:32 AM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Osvaldo Santana [EMAIL PROTECTED] wrote:
I've noticed this inconsistency when we stop to use zipimport in our
Python For Maemo distribution. We've decided to stop using zipimport
because the device (Nokia 770) uses a compressed
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 11/9/05, Osvaldo Santana [EMAIL PROTECTED] wrote:
I've noticed this inconsistency when we stop to use zipimport in our
Python For Maemo distribution. We've decided to stop using zipimport
because the device (Nokia 770) uses a
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z FILE.ZIP, and
2) the use of zipfiles is so poorly documented.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP, and
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
-bob
___
Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP, and
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
It should, yes -
On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP, and
This should work on a few platforms:
env PYTHONPATH=FILE.zip
Bob Ippolito wrote:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP, and
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
Really? I wrote the '-m' code, and
On 11/9/05, Bob Ippolito [EMAIL PROTECTED] wrote:
On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP, and
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
But I thought part of the point of .pyo files was that they left out
On Nov 9, 2005, at 6:05 PM, Brett Cannon wrote:
I would have no issue with removing .pyo files and have .pyc files
just be as optimized as they the current settings are and leave it at
that. Could have some metadata listing what optimizations occurred,
but do we really need to have a
On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote:
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
But I thought part of
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote:
Plus I wouldn't be
surprised if we started to move away from bytecode optimization and
instead tried to do more AST transformations which would remove
possible post-load optimizations.
At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote:
The only solutions I can think of that use a single file actually
*increase* the file size by having unoptimized and optimized code
side-by-side, or some way to quickly skip the assertions -- the -OO
option is a special case that probably needs
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote:
The only solutions I can think of that use a single file actually
*increase* the file size by having unoptimized and optimized code
side-by-side, or some way to quickly skip the assertions
[Guido]
However, this would be a major pain for the standard library and other
shared code -- there it's really nice to have a cache for each of the
optimization levels since usually regular users can't write the
.py[co] files there, meaning very slow always-recompilation if the
standard
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Guido]
However, this would be a major pain for the standard library and other
shared code -- there it's really nice to have a cache for each of the
optimization levels since usually regular users can't write the
.py[co] files
I like Phillip's suggestion -- no new opcode, just a conditional jump
that can be easily optimized out.
Huh? But Phillip is suggesting a new opcode that is essentially the
same as my proposal but naming it differently and saying the bytecode
should get changed directly instead of having
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I like Phillip's suggestion -- no new opcode, just a conditional jump
that can be easily optimized out.
Huh? But Phillip is suggesting a new opcode that is essentially the
same as my proposal but naming it differently and saying
On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote:
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I like Phillip's suggestion -- no new opcode, just a conditional jump
that can be easily optimized out.
Huh? But Phillip is suggesting a new opcode that is essentially the
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
Yeah, that's not bad, but I hate setting PYTHONPATH. I was thinking
more along the line of
python -z ZIPFILE
where python would look at the ZIPFILE to see if there's a top-level
module called
You didn't show us what's in the zip file. Can you show a zipinfo output?
My intention with import was always that without -O, *.pyo files are
entirely ignored; and with -O, *.pyc files are entirely ignored.
It sounds like you're saying that you want to change this so that .pyc
and .pyo are
36 matches
Mail list logo
