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?
python2-notebook is a leaf package (nothing in Fedora (build)requires
it). I'd like to drop it from rawhide. Any objections?
This **does not** affect the ability to run Jupyter Notebook (via the
jupyter-notebook command) with Python 2 kernel (from the
Dear python devel,
I just noticed that since Fedora 28, package python2-firewall is no longer
available and while I know that python2 packages nobody seems to rely on
are being gradually removed nowadays, I wonder why exactly was this
particular package removed.
The problem here is that without python2 module for firewalld, one can't
use an ansible playbook to reconfigure firewall on Fedora machine:
And while switching to python3 may solve this particular problem, I
don't think it's a reasonable solution from Fedora perspective, which:
* packages Ansible so that it runs on python 2
* provides Firewalld to manage firewall by default
Decision to drop python2-firewall then looks little weird, as it breaks
the general expectation that ansible playbook using firewalld module is
able to reconfigure firewall on a fedora machine. Moreover other python2
modules which some ansible modules are using such as python2-libselinux
or python2-dnf are still available, and dropping python2-firewall
doesn't look very consistent. That said, these python2 subpackages will
not be installed by default.
The other problem here is that it's not easy to spot such problem, as
this kind of dependency is not visible via rpm requirements (see eg. BZ
1505082 for explanation :). Maintainer dropping his python2 subpackage
could very easily miss this.
What do you think? Do we want to continue dropping python2 modules and
encourage people to reconfigure ansible to run under python 3 while
shipping ansible with python 2 or do we want to keep python2 modules
used by ansible available, even thouhg this is not easy to track right
And don't get me wrong, I'm a fan of switching to python3 and I agree
that helping ansible guys with python 3 testing and porting is good
for Fedora. I just don't think that dropping random packages from
distribution so that random modules doesn't work with default ansible
is a good way to do it.
At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told
me that he'd like to collect data about Release Candidates for point
releases (3.x.y). The idea is that if these aren't being tested and
aren't revealing bugs, it would make sense to stop releasing them.
So, please, if you find any bugs in upcoming Python *3.6.x* release
candidates, let me know (or write to Łukasz directly)! If there are no
such reports, there will be no 3.7.x RCs.
Also, are these useful for Fedora? Do/should we test 3.x.y RCs?
(3.x.0 pre-releases like the current 3.7.0 beta are a different matter;
those are obviously useful.)
I'd like to retire python33 from Fedora 29+.
Upstream has ended 3.3 support in September 2017 . It was security
only since October 2014.
Red Hat does not support 3.3 in any of the products (AFAIK). Software
collection python33 is EOL since Oct 2016 .
Python 3.3 was somehow important with OpenShift Online 2, because that
was the only out of the box working Python 3. OpenShift Online 2 is EOL
since December 2017 .
Debian jessie (oldstable) has Python 3.4. Debian wheezy (oldoldstable)
has 3.2 so that one is irrelevant anyway (regardless being oldold).
Ubuntu 14.04 LTS has 3.4. Ubuntu 12.04 LTS has EOLed in August 2017 and
had 3.2 anyway.
I see no reason a developer would need to test their code against Python
3.3 in 2018. However I might be missing something. If nobody speaks up,
I'll retire python33 in 1-2 weeks.
Probably some, or most, of you have already seen this but I
find Randall Munroe's cartoon right on the point (for most
issues and this about python is not an exception):