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).
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. 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. All this is btw. specified in PEP-3147: https://www.python.org/dev/peps/ pep-3147/#case-4-legacy-pyc-files-and-source-less-imports So, we actually would have: - a sources package, shared by python2 and python3 - a python2 bytecode package (usable standalone) - a python3 "sourceless" package, installing symlinks into the sources directory, conflicting with the python2 bytecode package) - a python3 bytecode package (depending on the sources or the sourceless package, not exclusive)
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. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org