On Fri, Feb 17, 2017 at 5:48 PM, Stefan Bruens <stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 17. Februar 2017 15:55:51 CET Todd Rme wrote:
On Fri, Feb 17, 2017 at 3:00 PM, Stefan Bruens
<stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 17. Februar 2017 20:08:53 CET Klaus Kaempf wrote:
* Kristoffer Grönlund <kgronlund@suse.com> [Feb 17. 2017 16:59]:
jan matejek <jmatejek@suse.com> writes:
5. dropping .py That's a big NO.
I just wanted to add my voice to this and agree wholeheartedly. As a developer, this would make the packaged python modules completely useless to me, as stepping into them with a debugger would no longer work.
Then you just install the python-X-source package. That could even be automated in zypper.
Maybe add Recomends: packageand(python-X, python-sources), so its easy to install sources for all installed python-packages and restore the current status quo.
Option 5) actually said dropping sources, which is IMHO either badly worded or just a bad idea.
Splitting out the sources (.py) from the bytecode (.pyc) would allow to remove any redundant data and have fast startup times. Especially for containers and small devices (RPi and alike) this would be a clear win. Probably most installed systems would never need the sources, and even developers will likely only need the sources of a few packages. Hands up, who has debuginfo/ debugsource installed for *all* their installed packages?
As others have said, Python is an interpreted language, not a compiled language like C. The .py files are the code that is executed. The .pyc files are just an optional cache. In fact recent versions of python put them in a __pycache__ directory.
Sorry to destroy your simplistic world view, but there are no compiled or interpreted languages. Source code gets parsed, optimized, stored in various intermediate forms, and finally transformed into machine specific bytecode (and later may be transformed again, e.g. current x86 CPUs, or translated again, e.g. qemu).
No, that simply isn't true. Some language are converted into machine code (which is not the same as bytecode) that is executed by the CPU, some aren't. At no point is CPython code converted into machine code. The CPython interpeter decides what pre-existing machine code to execute based on the Python bytecode, but the CPU never sees that bytecode. Pypy only compiles certain commonly-used code paths to machine code. Cython and Numba can only compile a restricted subset of Python functionality to machine code. No one has been able to make a Python machine code compiler that works with the full range of Python functionality.
More seriously, .pyc files are not intended for stand-alone use and Python is not designed to work this way. Python allows a lot of tinkering with its internals, so I would not count on the .pyc files even working reliably on their own, and the bugs that are introduced could be rare and hard to track down.
Ever wondered what happens if there *are* pyc bytecode files? Python *stats* the python source file, looks for a corresponding bytecode file in the (python2: source; python3: __pycache__) directory, reads the bytecode file header, compares the header timestamp with the change time from the earlier stat call, and executes the byte code. The contents of the source file are *not* read at all.
Depends, you can tell Python never to use .pyc files.
The valid question now is, what happens if there is no source file, to compare the timestamp against? This is completely valid from pythons perspective, called "sourceless" distribution, although the behaviour differs slightly between python2 and python3. Python2 just uses the python2 bytecode file from the source directory unconditionally. Python3 does not use the bytecode from the __pycache__ dir, but looks for a .pyc name file in the source directory.
Assuming the package doesn't use the "inspect" module or something like it to access the source code directly, which is completely valid in Python. I just checked on github, and there are more than 24,500 uses of "inspect.getsource" alone in github.
This won't even work by default in recent versions of python. As I mentioned, these files go in the __pycache__ directory by default, and python does not look there for code to execute. So we would need to change python from the upstream default behavior just to make this proposal work at all.
Tried it, it *does* work, and is specified by the python PEP linked above.
This contradicts what you said above: "Python3 does not use the bytecode from the __pycache__ dir, but looks for a .pyc name file in the source directory." So in order to make this work, we would need to deviate from the default Python behavior, either manually symlinking or changing the default python bytecode handling. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org