The first beta for Python 3.7 is out. It will hopefully get into Fedora
soon as python37.
After it comes out of beta, we'll upgrade python3 to it.
The What's New list is at: https://docs.python.org/3.7/whatsnew/3.7.html
One thing that's interesting for packagers is PEP 552: Deterministic
Let me summarize in my own words.
A new opt-in mode for byte-compilation makes .pyc (bytecode cache) files
depend only on the contents of the corresponding source file.
If we use this, it will slow down imports, because the whole source file
would need to be read and hashed in order to verify if a .pyc file is
valid. (Currently, metadata like the modification time and file size is
To speed things up, there's an option, UNCHECKED_HASH, which skips cache
validation entirely. Using this would mean that if you modify a .py
source file installed by RPM, the changes wouldn't take effect (the .py
contents would only be shown in tracebacks).
Modifying installed files in production is extremely bad practice, of
course, but it's quite useful for debugging on throw-away systems. If we
adopt UNCHECKED_HASH, anyone doing it will have to remember to remove
the corresponding .pyc file.
Honestly, I'm not sure we want to use this in Fedora. Is anyone here
into reproducible builds, to make a better argument for this?
On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
> We of the core dev community commit to supporting Python releases for
> five years. Releases get eighteen months of active bug fixes, followed
> by three and a half years of security fixes. Python 3.4 turns 5 next
> March--at which point we'll stop supporting it, and I'll retire as 3.4
> release manager.
> My plan is to make one final release on or around its fifth birthday
> containing the last round of security fixes. That's about seven
> months from now.
See also PEP 429 -- Python 3.4 Release Schedule .
We have python34 and python36 in EPEL7. python34 being the "main" one
and python36 the "other" one. The original plan  was that once the
ecosystem is adapted well enough, we can switch what "main" and "other"
is and eventually drop python34, creating room for maybe another python3
release to be the "other" next (python38 maybe?). Originally this was
supposed to happen for each release , but this was later abandoned
due to lack of manpower.
Do we want to ever switch "main" with "other"? The problem here is:
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' |
pkgname | sort | uniq | wc -l
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' |
pkgname | sort | uniq | wc -l
The original idea is that all packages would have the python3_other
macros in them  and all we need is rebuild everything in proper
order, maybe with some bootstrapping. However that never happened and
most of the packages I've seen lack the python3_other bits (no
statistics, just my impression).
Is this something we want? If so, are the packagers willing to adapt
their packages (as much as I'd like to do this, I lack the resources to
hack on 228 packages)?
The Python Maint team in Red Hat is here to help. However the drive
would need to come from the EPEL community, as now we are only guessing
what are the needs here.
In case you weren't aware, Matplotlib 3.0 will drop support for Python 2.
The rc1 was just released today/yesterday, though I have not yet attempted
to see how that update will go. The 2.2.x line will continue to be
supported and receive bug fixes until Python 2 is EOL.
So I'm wondering what exactly our plans are going forward for when the
final 3.0 release is made?
Hi, python3 no longer requires python3-setuptools and python3-pip;
python2 no longer requires python2-setuptools and python2-pip.
Those are just recommended. If you need them at build time, BR them.
+ /usr/bin/python2 setup.py build '--executable=/usr/bin/python2 -s'
Traceback (most recent call last):
File "setup.py", line 5, in <module>
from setuptools import setup
ImportError: No module named setuptools
We used to have /usr/bin/virtualenv-2 and /usr/bin/virtualenv in
python2-virtualenv. /usr/bin/virtualenv-3 in python3-virtualenv.
As of https://bugzilla.redhat.com/show_bug.cgi?id=1599422 this will
change on F29+. There will be just one /usr/bin/virtualenv.
If you need to specify python version of the created virtual
environment, use --python/-p:
$ virtualenv -p /usr/bin/python2.7 <venv_name>
$ virtualenv -p python3.7 <venv_name>
$ virtualenv -p pypy2 <venv_name>
$ virtualenv -p /opt/tauthon/bin/tauthon2.8 <venv_name>
If you omit -p, the Python version will be 3.7 on F29+, 2.7 before that.
I recommend always using the -p option explicitly to avoid surprises.
If you have Python 3.4+ (including PyPy), you can use the standard
library venv module instead (I recommend that):
$ python3.7 -m venv <venv_name>
$ pypy3 -m venv <venv_name>
Unlike virtualenv, here the interpreter that runs the venv module is the
same that will be used in the virtual environment.
If you really need to **run** virtualenv using python2, you can use -m:
$ python2 -m virtualenv --python=python3.7 <venv_name>
If you need to BuildRequire virtualenv from your packages, you can use:
(once the change is done on F29+), or:
(already now on any Fedora version)
PS virtualenv-2 and virtualenv-3 were Fedora specific hacks.
sorry for the late notice; Django 2.1 was recently released, and
I intend to update Django in F29 to version 2.1.
Apparently, all depending packages still build, all the details
If I don't hear anything against it until Monday, I'll merge rawhide into
Matthias Runge <mrunge(a)matthias-runge.de>