Re: [Python-Dev] Importing .pyc in -O mode and vice versa
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 option to remove docstrings of a .pyc file. I'm planning to send a patch that adds a "--remove-docs" to the Python interpreter to replace the "-OO" option that create only .pyo files. [1] http://mail.python.org/pipermail/python-dev/2005-November/057959.html 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 performance perspective, it would be nice if Python looked > > for *fewer* things, not more things. > > That's true. [cut] -- Osvaldo Santana Neto (aCiDBaSe) http://www.pythonologia.org ___ 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
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
[Python-Dev] Inconsistent behaviour in import/zipimport hooks
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/archive%40mail-archive.com
