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 o
On 11/14/05, Ulrich Berning <[EMAIL PROTECTED]> wrote:
> >You seem to forget the realities of backwards compatibility. While
> >there are ways to cache bytecode without having multiple extensions,
> >we probably can't do that until Python 3.0.
> >
> Please can you explain what backwards compatibili
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
>whe
> 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 .
Hi (first post here, note that English is not my native language),
One thing we shoudn't forgot is that Osvaldo is porting Python to a
plataform that has not so much disk space. He needs Python modules
with just the essencial.
I like ideias like __debug__ opcode, but in Osvaldo use case, there
are
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 b
Ulrich Berning schrieb:
[He already has a patch that does much of what is being discussed]
> I have also introduced the new flag Py_NoZipImport that
> can be activated with -Z at startup. This bypasses the
> activation of zipimport
I think -Z could be confusing; I would expect it to work more li
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
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
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 proc
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:
> >
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 i
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
> 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 "__
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 esse
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
> > 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 h
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[
[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
> >
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 ass
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 nee
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 opt
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 thoug
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 s
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
doc
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., "
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 th
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
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
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
_
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
Unsub
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
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 co
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 brainst
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 s
> 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 nothin
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, s
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 d
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 alwa
Hi,
I'm working on Python[1] port for Maemo Platform[2] and I've found a
inconsistent behavior in zipimport and import hook with '.pyc' and
'.pyo' files. The shell section below show this problem using a
'module_c.pyc', 'module_o.pyo' and 'modules.zip' (with module_c and
module_o inside):
$ ls
mo
40 matches
Mail list logo
