This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Loading -OO bytecode files if -O was requested can lead to problems
Type: behavior Stage: resolved
Components: Interpreter Core, Tests Versions: Python 3.3, Python 3.4, Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Sworddragon, brett.cannon, serhiy.storchaka
Priority: normal Keywords:

Created on 2013-11-09 05:57 by Sworddragon, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg202462 - (view) Author: (Sworddragon) Date: 2013-11-09 05:57
The documentation says that -OO does remove docstrings so applications should be aware of it. But there is also a case where a valid declared docstring isn't accessible anymore if -O is given. First the testcase:

import test2
def test1():

def test2():

A simple check will show the current result:

sworddragon@ubuntu:~/tmp$ python3 -BO

If -OO is given the docstrings will be removed as expected:

sworddragon@ubuntu:~/tmp$ python3 -OO

Now we have also bytecode files saved on the disk without any docstrings. But if we try to use only -O the problem appears:

sworddragon@ubuntu:~/tmp$ python3 -O

Even with only -O given we doesn't get the docstring for the imported module. The problem is that Python allows to load -OO bytecode files if -O bytecode was requested. I think the simplest solution would be to name -OO bytecode-files as .pyoo.
msg202475 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-11-09 09:09
Some tests fail when ran with -OO and then with -O. Short example (there are more examples):

$ rm -rf Lib/test/__pycache__
$ ./python -OO -m test.regrtest test_property
[1/1] test_property
1 test OK.
$ ./python -O -m test.regrtest test_property
[1/1] test_property
test test_property failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
msg202484 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-11-09 16:04
This is a known problem and has been brought up over the years. Discussions have typically revolved around expanding the .pyc format to encode what optimizations were used so if the interpreter was using different optimizations it would not use the bytecode.
msg363549 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2020-03-06 20:40
.pyc files now include their optimization levels in their file names.
Date User Action Args
2022-04-11 14:57:53adminsetgithub: 63730
2020-03-06 20:40:08brett.cannonsetstatus: open -> closed
resolution: fixed
messages: + msg363549

stage: resolved
2014-05-22 22:13:27skrahsetnosy: - skrah
2013-11-09 16:04:01brett.cannonsetnosy: + brett.cannon
messages: + msg202484
2013-11-09 09:09:07serhiy.storchakasetversions: + Python 2.7, Python 3.4
nosy: + skrah, serhiy.storchaka

messages: + msg202475

components: + Tests
type: enhancement -> behavior
2013-11-09 05:57:27Sworddragoncreate