What is the use of the "-O" flag for running Python?
Question:
Answers:
Removing assertions means a small performance benefit, so you could use this for “release” code. Anyway nobody uses it because many Python libraries are open sourced and thus the help() function should work.
So, as long as there isn’t any real optimization in this mode, you can ignore it.
Prepacked software in different Linux distributions often comes byte-compiled with -O. For example, this if from Fedora packaging guidelines for python applications:
In the past it was common practice to %ghost .pyo files in order to save a small amount of space on the users filesystem. However, this has two issues: 1. With SELinux, if a user is running python -O [APP] it will try to write the .pyos when they don’t exist. This leads to AVC denial records in the logs. 2. If the system administrator runs python -OO [APP] the .pyos will get created with no docstrings. Some programs require docstrings in order to function. On subsequent runs with python -O [APP] python will use the cached .pyos even though a different optimization level has been requested. The only way to fix this is to find out where the .pyos are and delete them.
The current method of dealing with pyo files is to include them as is, no %ghosting.
It saves a small amount of memory, and a small amount of disk space if you distribute any archive form containing only the .pyo files. (If you use assert a lot, and perhaps with complicated conditions, the savings can be not trivial and can extend to running time too).
So, it’s definitely not useless — and of course it’s being used (if you deploy a Python-coded server program to a huge number N of server machines, why ever would you want to waste N * X bytes to keep docstrings which nobody, ever, would anyway be able to access?!). Of course it would be better if it saved even more, but, hey — waste not, want not!-)
So it’s pretty much a no-brainer to keep this functionality (which is in any case trivially simple to provide, you know;-) in Python 3 — why add even “epsilon” to the latter’s adoption difficulties?-)
python -O does the following currently:
- completely ignores asserts
- sets the special builtin name
__debug__ to False (which by default is True)
and when called as python -OO
- removes docstrings from the code
I don’t know why everyone forgets to mention the __debug__ issue; perhaps it is because I’m the only one using it 🙂 An if __debug__ construct creates no bytecode at all when running under -O, and I find that very useful.
Removing assertions means a small performance benefit, so you could use this for “release” code. Anyway nobody uses it because many Python libraries are open sourced and thus the help() function should work.
So, as long as there isn’t any real optimization in this mode, you can ignore it.
Prepacked software in different Linux distributions often comes byte-compiled with -O. For example, this if from Fedora packaging guidelines for python applications:
In the past it was common practice to %ghost .pyo files in order to save a small amount of space on the users filesystem. However, this has two issues: 1. With SELinux, if a user is running python -O [APP] it will try to write the .pyos when they don’t exist. This leads to AVC denial records in the logs. 2. If the system administrator runs python -OO [APP] the .pyos will get created with no docstrings. Some programs require docstrings in order to function. On subsequent runs with python -O [APP] python will use the cached .pyos even though a different optimization level has been requested. The only way to fix this is to find out where the .pyos are and delete them.
The current method of dealing with pyo files is to include them as is, no %ghosting.
It saves a small amount of memory, and a small amount of disk space if you distribute any archive form containing only the .pyo files. (If you use assert a lot, and perhaps with complicated conditions, the savings can be not trivial and can extend to running time too).
So, it’s definitely not useless — and of course it’s being used (if you deploy a Python-coded server program to a huge number N of server machines, why ever would you want to waste N * X bytes to keep docstrings which nobody, ever, would anyway be able to access?!). Of course it would be better if it saved even more, but, hey — waste not, want not!-)
So it’s pretty much a no-brainer to keep this functionality (which is in any case trivially simple to provide, you know;-) in Python 3 — why add even “epsilon” to the latter’s adoption difficulties?-)
python -O does the following currently:
- completely ignores asserts
- sets the special builtin name
__debug__to False (which by default is True)
and when called as python -OO
- removes docstrings from the code
I don’t know why everyone forgets to mention the __debug__ issue; perhaps it is because I’m the only one using it 🙂 An if __debug__ construct creates no bytecode at all when running under -O, and I find that very useful.