Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 file, not a .pyo file. Because we always generate bytecode with -OO at distribution time, we either had to change the behavior of pythonservice.exe or change the import behavior of Python. While ignoring the question of how Python should in the future handle optimizations, I think it safe to state that that pythonservice.exe should have the same basic functionality and operation in this regard as python.exe does. It doesn't sound too difficult to modify pythonservice to accept -O flags, and to modify the service installation process to allow this flag to be specified. I'd certainly welcome any such patches. Although getting off-topic for this list, note that for recent pywin32 releases, it is possible to host a service using python.exe directly, and this is the technique py2exe uses to host service executables. It would take a little more work to set things up to work like that, but that's probably not too unreasonable for a custom application with specialized distribution requirements. Using python.exe obviously means you get full access to the command-line facilities it provides. Although off-topic for this list, I should give a reply. I have done both. My first approach was to change pythonservice.exe to accept -O and -OO and set the Py_OptimizeFlag accordingly. Today, we aren't using pythonservice.exe any longer. I have done nearly all the required changes in win32serviceutil.py to let python.exe host the services. It requires no changes to the services, everything should work as before. The difference is, that the service module is always executed as a script now. This requires an additional (first) argument '--as-service' when the script runs as a service. NOTE: Debugging services doesn't work yet. --- Installing the service C:\svc\testService.py is done the usual way: C:\svcC:\Python23\python.exe testService.py install The resulting ImagePath value in the registry is then: C:\Python23\python.exe C:\svc\testService.py --as-service After finishing development and testing, we convert the script into an executable with our own tool sib.py: C:\svcC:\Python23\python.exe C:\Python23\sib.py -n testService -d . testService.py C:\svcnmake Now, we just do: C:\svctestService.exe update The resulting ImagePath value in the registry is then changed to: C:\testService.exe --as-service Starting, stopping and removing works as usual: C:\svctestService.exe start C:\svctestService.exe stop C:\svctestService.exe remove --- Because not everything works as before (debugging doesn't work, but we do not use it), I haven't provided a patch yet. As soon as I have completed it, I will have a patch available. Ulli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 happens. With Python you don't. When you first run your program with -O but it crashes, and then you run it again without -O to enable assertions, you would be very unhappy if the bytecode cached in a .pyo file would be reused! The other way round makes definitely more sense. At development time, I would never use Python with -O or -OO. I use it only at distribution time, after doing all the tests, to generate optimized bytecode. However, this problem could be easily solved, if the value of Py_OptimizeFlag would be stored together with the generated bytecode. At import time, the cached bytecode would not be reused if the current value of Py_OptimizeFlag doesn't match the stored value (if the .py file isn't there any longer, we could either raise an exception or we could emit a warning and reuse the bytecode anyway). And if we do this a little bit more clever, we could refuse reusing optimized bytecode if we are running without -O or -OO and ignore assertions and docstrings in unoptimized bytecode when we are running with -O or -OO. I would appreciate to see the generation of .pyo files completely removed in the next release. 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 compatibility means in this context? Generated bytecode is neither upwards nor backwards compatible. No matter what I try, I always get a 'Bad magic number' when I try to import bytecode generated with a different Python version. The most obvious software, that may depend on the existence of .pyo files are the various freeze/packaging tools like py2exe, py2app, cx_Freeze and Installer. I haven't checked them in detail, but after a short inspection, they seem to be independent of the existence of .pyo files. I can't imagine that there is any other Python software, that depends on the existence of .pyo files, but maybe I'm totally wrong in this wild guess. Ulli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 file. Because we always generate bytecode with -OO at distribution time, we either had to change the behavior of pythonservice.exe or change the import behavior of Python. While ignoring the question of how Python should in the future handle optimizations, I think it safe to state that that pythonservice.exe should have the same basic functionality and operation in this regard as python.exe does. It doesn't sound too difficult to modify pythonservice to accept -O flags, and to modify the service installation process to allow this flag to be specified. I'd certainly welcome any such patches. Although getting off-topic for this list, note that for recent pywin32 releases, it is possible to host a service using python.exe directly, and this is the technique py2exe uses to host service executables. It would take a little more work to set things up to work like that, but that's probably not too unreasonable for a custom application with specialized distribution requirements. Using python.exe obviously means you get full access to the command-line facilities it provides. So while I believe your idead for getting and setting these flags sounds reasonable, and also believe that at face value the zipimport semantics appear sane, I'm not sure we should use a weakness in a Python tool to justify a change to Python itself. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 exec another Python process whenever you want to compile
code with
a different optimization level than what's currently in effect, whereas if
it could pass the desired level to compile(), this wouldn't be necessary.
Makes sense to me; we need a patch of course.
But before we can do that, it's not clear to me if it should be part of the
existing flags argument, or whether it should be separate. Similarly,
whether it's just going to be a level or an optimization bitmask in its own
right might be relevant too.
For the current use case, obviously, a level argument suffices, with 'None'
meaning whatever the command-line level was for backward
compatibility. And I guess we could go with that for now easily enough,
I'd just like to know whether any of the AST or optimization mavens had
anything they were planning in the immediate future that might affect how
the API addition should be structured.
I'm using a totally different approach for the above problem. I have
implemented two functions in the sys module, that make the startup flags
accessible at runtime. This also solves some other problems I had, as
you will see in the examples below:
The first function makes most of the flags readable (I have ommited the
flags, that are documented as deprecated in the code):
sys.getrunflag(name) - integer
Return one of the interpreter run flags. Possible names are 'Optimize',
'Verbose', 'Interactive', 'IgnoreEnvironment', 'Debug',
'DivisionWarning', 'NoSite', 'NoZipImport', 'UseClassExceptions',
'Unicode', 'Frozen', 'Tabcheck'. getrunflag('Optimize') for example
returns the current value of Py_OptimizeFlag.
The second function makes a few flags writable:
sys.setrunflag(name, value) - integer
Set an interpreter run flag. The only flags that can be changed at
runtime are Py_VerboseFlag ('Verbose') and Py_OptimizeFlag ('Optimize').
Returns the previous value of the flag.
As you can see, I have also introduced the new flag Py_NoZipImport that
can be activated with -Z at startup. This bypasses the activation of
zipimport and is very handy, if you edit modules stored in the
filesystem, that are normally imported from a zip archive and you want
to test your modifications. With this flag, there is no need to delete,
rename or update the zip archive or to modify sys.path to ensure that
your changed modules are imported from the filesystem and not from the
zip archive.
And here are a few usable examples for the new functions:
1.) You have an application, that does a huge amount of imports and
some of them are mysterious, so you want to track them in verbose mode.
You could start python with -v or -vv, but then you get hundreds or
thousands of lines of output. Instead, you can do the following:
import sys
import ...
import ...
oldval = sys.setrunflag('Verbose', 1) # -v, use 2 for -vv
import ...
import ...
sys.setrunflag('Verbose', oldval)
import ...
import ...
Now, you get only verbose messages for the imports that you want to track.
2.) You need to generate optimized byte code (without assertions and
docstrings) from a source code, no matter how the interpreter was started:
import sys
...
source = ...
oldval = sys.setrunflag('Optimize', 2) # -OO, use 1 for -O
bytecode = compile(source, ...)
sys.setrunflag('Optimize', oldval)
...
3.) You have to build a command line for the running application (e.g.
for registration in the registry) and need to check, if you are running
a script or a frozen executable (this assumes, that your freeze tool
sets the Py_FrozenFlag):
import sys
...
if sys.getrunflag('Frozen'):
commandline = sys.executable
else:
commandline = '%s %s' % (sys.executable, sys.argv[0])
...
NOTE: My own freeze tool sib.py, which is part of the VendorID package
(www.riverbankcomputing.co.uk/vendorid) doesn't set the Py_FrozenFlag
yet. I will provide an update soon.
And now back to the original subject:
I have done nearly the same changes, that Osvaldo provided with his
patch and I would highly appreciate if this patch goes into the next
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 file. Because we always generate bytecode
with -OO at distribution time, we either had to change the behavior of
pythonservice.exe or change the import behavior of Python.
It is essential for us to remove assertions and docstrings in our
commercial Python applications at distribution time, because assertions
are
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 me. 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 happens. With Python you don't. When you first run your program with -O but it crashes, and then you run it again without -O to enable assertions, you would be very unhappy if the bytecode cached in a .pyo file would be reused! I would appreciate to see the generation of .pyo files completely removed in the next release. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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, and This should work on a few platforms: env PYTHONPATH=FILE.zip python -m some_module_in_the_zip It should, yes - but it doesn't: -m doesn't work with zipimport. That's dumb, someone should fix that. Is there a bug filed? I did, a while ago. http://www.python.org/sf/1250389 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 simple). The PEP and the associated patch currently only cover lifting the limitation against executing modules inside packages, but it should be possible to extend it to cover executing modules inside zip files as well (as you say, increasing use of eggs will only make the current limitations more annoying). That discussion should probably happen on c.l.p, though. cc' me if you start one, and I can keep on eye on it through Google (I won't have time to participate actively, unfortunately :() Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 simple). Oops, that should be PEP 3*3*8. PEP 328 is something completely different. That'll teach me to post without checking the PEP number ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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) 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 - but it doesn't: -m doesn't work with zipimport. That's dumb, someone should fix that. Is there a bug filed? I did, a while ago. http://www.python.org/sf/1250389 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 simple). The PEP and the associated patch currently only cover lifting the limitation against executing modules inside packages, but it should be possible to extend it to cover executing modules inside zip files as well (as you say, increasing use of eggs will only make the current limitations more annoying). That discussion should probably happen on c.l.p, though. cc' me if you start one, and I can keep on eye on it through Google (I won't have time to participate actively, unfortunately :() I didn't respond simply because it seemed obvious that this should go in, and I expected no debate. I assumed the only reason it didn't go into 2.4 was because the issue came up too close to the release. Teach me to assume, I guess... FWIW, I'm +1 on PEP 338. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 whenever you want to compile code with a different optimization level than what's currently in effect, whereas if it could pass the desired level to compile(), this wouldn't be necessary. Makes sense to me; we need a patch of course. But before we can do that, it's not clear to me if it should be part of the existing flags argument, or whether it should be separate. Similarly, whether it's just going to be a level or an optimization bitmask in its own right might be relevant too. For the current use case, obviously, a level argument suffices, with 'None' meaning whatever the command-line level was for backward compatibility. And I guess we could go with that for now easily enough, I'd just like to know whether any of the AST or optimization mavens had anything they were planning in the immediate future that might affect how the API addition should be structured. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 distutils has to actually exec another Python process whenever you want to compile code with a different optimization level than what's currently in effect, whereas if it could pass the desired level to compile(), this wouldn't be necessary. Makes sense to me; we need a patch of course. But before we can do that, it's not clear to me if it should be part of the existing flags argument, or whether it should be separate. Similarly, whether it's just going to be a level or an optimization bitmask in its own right might be relevant too. For the current use case, obviously, a level argument suffices, with 'None' meaning whatever the command-line level was for backward compatibility. And I guess we could go with that for now easily enough, I'd just like to know whether any of the AST or optimization mavens had anything they were planning in the immediate future that might affect how the API addition should be structured. I'm not a big user of this API, please design as you see fit. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 defN 31-Oct-05 14:48 module_c.pyc 2 files, 218 bytes uncompressed, 136 bytes compressed: 37.6% 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 always honored (with .pyc preferred if -O is not present and .pyo preferred if -O is present). I'm not sure that I like that better. If that's how zipimport works, I think it's broken! Yes, this is how zipimport works and I think this is good in cases where a third-party binary module/package is available only with .pyo files and others only with .pyc files (without .py source files, of course). I know we can rename the files, but this is a good solution? Well, I don't have a strong opinion about the solution adopted and I really like to see other alternatives and opinions. Thanks, Osvaldo -- Osvaldo Santana Neto (aCiDBaSe) icq, url = (11287184, http://www.pythonbrasil.com.br;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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, so the use case for changing things isn't very strong. In fact the only use cases I know for not making .py available are in situations where a proprietary canned application is distributed to end users who have no intention or need to ever add to the code. --Guido On 11/9/05, Osvaldo Santana [EMAIL PROTECTED] wrote: 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 defN 31-Oct-05 14:48 module_c.pyc 2 files, 218 bytes uncompressed, 136 bytes compressed: 37.6% 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 always honored (with .pyc preferred if -O is not present and .pyo preferred if -O is present). I'm not sure that I like that better. If that's how zipimport works, I think it's broken! Yes, this is how zipimport works and I think this is good in cases where a third-party binary module/package is available only with .pyo files and others only with .pyc files (without .py source files, of course). I know we can rename the files, but this is a good solution? Well, I don't have a strong opinion about the solution adopted and I really like to see other alternatives and opinions. Thanks, Osvaldo -- Osvaldo Santana Neto (aCiDBaSe) icq, url = (11287184, http://www.pythonbrasil.com.br;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 will happen. The status quo is good enough, for normal imports. If zipimport works differently, well, that's not nice. I've never heard of a third party making their code available only as .pyo, *cough* Ahem, here we are (the firm I work for). so the use case for changing things isn't very strong. In fact the only use cases I know for not making .py available are in situations where a proprietary canned application is distributed to end users who have no intention or need to ever add to the code. Well, exactly. :-) -- Nicola Larosa - [EMAIL PROTECTED] No inventions have really significantly eased the cognitive difficulty of writing scalable concurrent applications and it is unlikely that any will in the near term. [...] Most of all, threads do not help, in fact, they make the problem worse in many cases. -- G. Lefkowitz, August 2005 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 in his e-mail). Maybe we want to create a different and optimization-independent option to remove docstrings from modules? Unless others are interested in this nothing will happen. I've never heard of a third party making their code available only as .pyo, so the use case for changing things isn't very strong. In fact the only use cases I know for not making .py available are in situations where a proprietary canned application is distributed to end users who have no intention or need to ever add to the code. I've other use case: I'm porting Python to Maemo Platform and I want to reduce the size of modules. The .pyo (-OO) are smaller than .pyc files (mainly because docstring removing) and we start to use this optimization flag to compile our Python distribution. In this case we want to force developers to call Python Interpreter with -O flags, set PYTHONOPTIMIZE, or apply my patch :) to make this more transparent. 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. Some friends (mainly Gustavo Barbieri) help me to create the suggested patch after some discussion in our PythonBrasil mailing list. Thanks, Osvaldo -- Osvaldo Santana Neto (aCiDBaSe) icq, url = (11287184, http://www.pythonbrasil.com.br;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 that's going on (this is becoming a topic for c.l.py) but I think you are misunderstanding the point of zipimport. It's not done (usually) for the compression but for the index. Finding a name in the zipfile index is much more efficient than doing a directory search; and the zip index can be cached. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 filesystem. I won't comment further on the brainstorm that's going on (this is becoming a topic for c.l.py) but I think you are misunderstanding the point of zipimport. It's not done (usually) for the compression but for the index. Finding a name in the zipfile index is much more efficient than doing a directory search; and the zip index can be cached. zipimport also helps distribution convenience - a large and elaborate package can be distributed in a single zipfile (such as is built by setuptools' bdist_egg command) and simply placed on PYTHONPATH or directly on sys.path. And tools like py2exe can also append all an application's modules to an executable file in zipped form. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 compressed filesystem. I won't comment further on the brainstorm that's going on (this is becoming a topic for c.l.py) but I think you are misunderstanding the point of zipimport. It's not done (usually) for the compression but for the index. Finding a name in the zipfile index is much more efficient than doing a directory search; and the zip index can be cached. Any way, not loading .pyo if no .pyc or .py is available is a drawback, specially on unices that have scripts starting with #!/usr/bin/python or #!/usr/bin/env python and the system just have .pyo files, due a bunch of reasons, in this case the small disc space. -- Gustavo Sverzut Barbieri -- Computer Engineer 2001 - UNICAMP Mobile: +55 (19) 9165 8010 Phone: +1 (347) 624 6296 @ sip.stanaphone.com Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 - but it doesn't: -m doesn't work with zipimport. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 python -m some_module_in_the_zip It should, yes - but it doesn't: -m doesn't work with zipimport. That's dumb, someone should fix that. Is there a bug filed? -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 I wouldn't expect that to work anywhere because 'execfile' and the C equivalent that -m relies on expect a real file. PEP 328 goes some way towards fixing that by having a Python fallback to find and execute the module if the current C code fails. If we had execmodule as a Python function, it would make it much easier to add support for compiling and executing the target module directly, rather than indirecting through the file-system-dependent execfile. In theory this could be done in C, but execmodule is fairly long even written in Python. I'm actually fairly sure it *could* be written in C, but I think doing so would be horribly tedious (and not as useful in the long run). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 This should work on a few platforms: env PYTHONPATH=FILE.zip python -m some_module_in_the_zip It should, yes - but it doesn't: -m doesn't work with zipimport. That's dumb, someone should fix that. Is there a bug filed? I did, a while ago. http://www.python.org/sf/1250389 Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 docstrings and thus had a smaller footprint? 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. 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 specific way to denote if bytecode has been optimized? Binary files compiled from C don't note what -O optimization they were compiled with. If someone distributes optimized .pyc files chances are they are going to have a specific compile step with py_compile and they will know what optimizations they are using. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 specific way to denote if bytecode has been optimized? Binary files compiled from C don't note what -O optimization they were compiled with. If someone distributes optimized .pyc files chances are they are going to have a specific compile step with py_compile and they will know what optimizations they are using. This sounds quite sensible. The only thing I'd add is that iff there is a .py file of the same name, and the current optimization settings are different from those in the .pyc file, python should recompile the .py file. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 the point of .pyo files was that they left out docstrings and thus had a smaller footprint? Very few people care about the smaller footprint (although one piped up here). 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. 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 specific way to denote if bytecode has been optimized? Binary files compiled from C don't note what -O optimization they were compiled with. If someone distributes optimized .pyc files chances are they are going to have a specific compile step with py_compile and they will know what optimizations they are using. Currently, .pyo files have some important semantic differences with .pyc files; -O doesn't remove docstrings (that's -OO) but it does remove asserts. I wouldn't want to accidentally use a .pyc file without asserts compiled in unless the .py file wasn't around. For application distribution, the following probably would work: - instead of .pyo files, we use .pyc files - the .pyc file records whether optimizations were applied, whether asserts are compiled, and whether docstrings are retained - if the compiler finds a .pyc that is inconsistent with the current command line, it ignores it and rewrites it (if it is writable) just as if the .py file were newer 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 .pyc files aren't of the right level, causing unacceptable start-up times. 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 to be done differently anyway and only for final distribution. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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. 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 specific way to denote if bytecode has been optimized? Binary files compiled from C don't note what -O optimization they were compiled with. If someone distributes optimized .pyc files chances are they are going to have a specific compile step with py_compile and they will know what optimizations they are using. Currently, .pyo files have some important semantic differences with .pyc files; -O doesn't remove docstrings (that's -OO) but it does remove asserts. I wouldn't want to accidentally use a .pyc file without asserts compiled in unless the .py file wasn't around. For application distribution, the following probably would work: - instead of .pyo files, we use .pyc files - the .pyc file records whether optimizations were applied, whether asserts are compiled, and whether docstrings are retained - if the compiler finds a .pyc that is inconsistent with the current command line, it ignores it and rewrites it (if it is writable) just as if the .py file were newer 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 .pyc files aren't of the right level, causing unacceptable start-up times. What if PEP 304 came into being? Then people would have a place to have the shared code's recompiled version stored and thus avoid the overhead from repeated use. 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 to be done differently anyway and only for final distribution. One option would be to introduce an ASSERTION bytecode that has an argument specifying the amount of bytecode for the assertion. The eval loop can then just igonore the bytecode if assertions are being evaluated and fall through to the bytecode for the assertions (and thus be the equivalent of NOP) or use the argument to jump forward that number of bytes in the bytecode and completely skip over the assertion (and thus be just like a JUMP_FORWARD). Either way assertions becomes slightly more costly but it should be very minimal. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 to be done differently anyway and only for final distribution. We could have a JUMP_IF_NOT_DEBUG opcode to skip over asserts and if __debug__ blocks. Then under -O we could either patch this to a plain jump, or compact the bytecode to remove the jumped-over part(s). 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 whenever you want to compile code with a different optimization level than what's currently in effect, whereas if it could pass the desired level to compile(), this wouldn't be necessary. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 -- the -OO option is a special case that probably needs to be done differently anyway and only for final distribution. We could have a JUMP_IF_NOT_DEBUG opcode to skip over asserts and if __debug__ blocks. Then under -O we could either patch this to a plain jump, or compact the bytecode to remove the jumped-over part(s). That sounds very reasonable. 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 whenever you want to compile code with a different optimization level than what's currently in effect, whereas if it could pass the desired level to compile(), this wouldn't be necessary. Makes sense to me; we need a patch of course. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
[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 .pyc files aren't of the right level, causing unacceptable start-up times. [Brett] What if PEP 304 came into being? Then people would have a place to have the shared code's recompiled version stored and thus avoid the overhead from repeated use. Still sounds suboptimal for the standard library; IMO it should just work. 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 to be done differently anyway and only for final distribution. One option would be to introduce an ASSERTION bytecode that has an argument specifying the amount of bytecode for the assertion. The eval loop can then just igonore the bytecode if assertions are being evaluated and fall through to the bytecode for the assertions (and thus be the equivalent of NOP) or use the argument to jump forward that number of bytes in the bytecode and completely skip over the assertion (and thus be just like a JUMP_FORWARD). Either way assertions becomes slightly more costly but it should be very minimal. I like Phillip's suggestion -- no new opcode, just a conditional jump that can be easily optimized out. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 there, meaning very slow always-recompilation if the standard .pyc files aren't of the right level, causing unacceptable start-up times. [Brett] What if PEP 304 came into being? Then people would have a place to have the shared code's recompiled version stored and thus avoid the overhead from repeated use. Still sounds suboptimal for the standard library; IMO it should just work. Fair enough. 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 to be done differently anyway and only for final distribution. One option would be to introduce an ASSERTION bytecode that has an argument specifying the amount of bytecode for the assertion. The eval loop can then just igonore the bytecode if assertions are being evaluated and fall through to the bytecode for the assertions (and thus be the equivalent of NOP) or use the argument to jump forward that number of bytes in the bytecode and completely skip over the assertion (and thus be just like a JUMP_FORWARD). Either way assertions becomes slightly more costly but it should be very minimal. 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 the eval loop handle the semantic differences based on whether -O is being used. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 the eval loop handle the semantic differences based on whether -O is being used. Sorry. Looking back they look pretty much the same to me. Somehow I glanced over Phillip's code and thought he was proposing to use a regular JUMP_IF opcode with the special __debug__ variable (which would be a 3rd possibility, good if we had backwards compatibility requirements for bytecode -- which we don't, fortunately :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 the bytecode should get changed directly instead of having the eval loop handle the semantic differences based on whether -O is being used. Sorry. No problem. Figured you just misread mine. Looking back they look pretty much the same to me. Somehow I glanced over Phillip's code and thought he was proposing to use a regular JUMP_IF opcode with the special __debug__ variable (which would be a 3rd possibility, good if we had backwards compatibility requirements for bytecode -- which we don't, fortunately :-). Fortunately. =) So does this mean you like the idea? Should this all move forward somehow? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 same as my proposal but naming it differently and saying the bytecode should get changed directly instead of having the eval loop handle the semantic differences based on whether -O is being used. Sorry. No problem. Figured you just misread mine. Looking back they look pretty much the same to me. Somehow I glanced over Phillip's code and thought he was proposing to use a regular JUMP_IF opcode with the special __debug__ variable (which would be a 3rd possibility, good if we had backwards compatibility requirements for bytecode -- which we don't, fortunately :-). Fortunately. =) So does this mean you like the idea? Should this all move forward somehow? I guess so. :-) It will need someone thinking really hard about all the use cases, edge cases, etc., implementation details, and writing up a PEP. Feel like volunteering? You might squeeze Phillip as a co-author. He's a really good one. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 __init__, and if so, load it. That would allow existing PYTHONPATH settings to still be used if the user cares. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
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 always honored (with .pyc preferred if -O is not present and .pyo preferred if -O is present). I'm not sure that I like that better. If that's how zipimport works, I think it's broken! --Guido On 11/8/05, Osvaldo Santana Neto [EMAIL PROTECTED] wrote: 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 module_c.pyc module_o.pyo modules.zip $ python import module_c import module_o ImportError: No module named module_o $ python -O import module_c ImportError: No module named module_c import module_o $ rm *.pyc *.pyo $ PYTHONPATH=modules.zip python import module_c module_c import module_o module_o $ PYTHONPATH=modules.zip python -O import module_c module_c import module_o module_o I've create a patch suggestion to remove this inconsistency[3] (*I* think zipimport behaviour is better). [1] http://pymaemo.sf.net/ [2] http://www.maemo.org/ [3] http://python.org/sf/1346572 -- Osvaldo Santana Neto (aCiDBaSe) icq, url = (11287184, http://www.pythonbrasil.com.br;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
