python-devel August 2018

python-devel@lists.fedoraproject.org

17 participants
16 discussions

Python 3.7's Deterministic pycs
by Petr Viktorin 15 Jul '19

15 Jul '19

Hello! 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 pycs: https://www.python.org/dev/peps/pep-0552/ 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 used.) 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? -- Petr Viktorin

5 5

EPEL: Python 3.4 will be EOL in March 2019
by Miro Hrončok 23 Oct '18

23 Oct '18

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 [0]. We have python34 and python36 in EPEL7. python34 being the "main" one and python36 the "other" one. The original plan [1] 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 [2], 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 243 $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' | pkgname | sort | uniq | wc -l 15 The original idea is that all packages would have the python3_other macros in them [2] 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. [0] https://www.python.org/dev/peps/pep-0429/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraprojec… [2] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 2

Plans for Matplotlib 3.0+
by Elliott Sales de Andrade 29 Sep '18

29 Sep '18

Hi all, 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? -- Elliott

4 16

python2 doesn't require setuptools anymore
by Igor Gnatenko 29 Aug '18

29 Aug '18

So finally this will force people to put proper BRs :) ---------- Forwarded message --------- From: <notifications(a)fedoraproject.org> Date: Wed, Aug 29, 2018, 07:06 Subject: python-parse's builds started to fail in Fedora rawhide To: <ignatenkobrain(a)fedoraproject.org> Notification time stamped 2018-08-29 05:06:26 UTC python-parse's builds started to fail in Fedora rawhide https://apps.fedoraproject.org/koschei/package/python-parse?collection=f30 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications/ignatenkobrain.id.fedoraprojec… -- -Igor Gnatenko

2 1

[HEADS UP] pythonX no longer requires setuptools and pip
by Miro Hrončok 29 Aug '18

29 Aug '18

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 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

[HEADS UP] There will be no virtualenv-2 and virtualenv-3, just virtualenv
by Miro Hrončok 23 Aug '18

23 Aug '18

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: BuildRequires: virtualenv (once the change is done on F29+), or: BuildRequires: /usr/bin/virtualenv (already now on any Fedora version) PS virtualenv-2 and virtualenv-3 were Fedora specific hacks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Intent to retire python modules
by Miro Hrončok 23 Aug '18

23 Aug '18

I'm going to retire (in a ~week): https://src.fedoraproject.org/modules/python https://src.fedoraproject.org/modules/python2 https://src.fedoraproject.org/modules/python2-bootstrap https://src.fedoraproject.org/modules/python2-ecosystem https://src.fedoraproject.org/modules/python3 https://src.fedoraproject.org/modules/python3-bootstrap https://src.fedoraproject.org/modules/python3-ecosystem This is f28 cruft from the "older modularity". Not used, not needed. Correct me if I'm wrong. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Intent to upgrade Django in f29 to 2.1
by Matthias Runge 22 Aug '18

22 Aug '18

Hello, 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 in https://bugzilla.redhat.com/show_bug.cgi?id=1611025 If I don't hear anything against it until Monday, I'll merge rawhide into F29. Matthias -- Matthias Runge <mrunge(a)matthias-runge.de>

2 3

Starting to use gcc-8 on upstream Python project CI
by Jun Aruga 21 Aug '18

21 Aug '18

Dear Python sig. Someone can you help to promote for the upstream Python project to use gcc-8 on the Travis CI test? Right now the project has 4 test cases [1] including defaut gcc version 4.8 cases on Travis CI. However technically it is possible to use gcc-N (4.8, 5, 6, 7, 8, and etc) on Travis CI. I think that using the latest version gcc-8 on the upstream project is quite beneficial for us. Because maybe we Fedora people are working to fix new version gcc's issues. When the python project start to use gcc-8, it is easy to share the situation publicly outside of Fedora, and of course they can help to check the issues. As I checked the Python project's .travis.yml, I had no idea about how to add gcc-8 case. ;( I can show you 2 cases to use the technique as an example. [2][3] [1] Python https://travis-ci.org/python/cpython https://github.com/python/cpython/blob/master/.travis.yml [2] Ruby https://travis-ci.org/junaruga/ruby/builds/418242410 https://github.com/junaruga/ruby/blob/feature/ci-new-gcc/.travis.yml https://github.com/ruby/ruby/pull/1937 [3] A project I am working as a hobby. https://travis-ci.org/trinityrnaseq/trinityrnaseq https://github.com/trinityrnaseq/trinityrnaseq/blob/master/.travis.yml -- Jun Aruga jaruga(a)redhat.com

2 2

Fwd: [RELEASED] Python 3.4.9 and Python 3.5.6 are now available
by Miro Hrončok 09 Aug '18

09 Aug '18

Available in updates-testing, please karma it: https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc28 https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc27 https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc28 https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc27 -------- Forwarded Message -------- Subject: [Python-Dev] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available Date: Thu, 2 Aug 2018 07:00:11 -0700 From: Larry Hastings <larry(a)hastings.org> To: python-announce(a)python.org, Python-Dev <python-dev(a)python.org>, python-list(a)python.org, python-committers <python-committers(a)python.org> On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.9 and Python 3.5.6. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.9 here: https://www.python.org/downloads/release/python-349/ And you can find Python 3.5.6 here: https://www.python.org/downloads/release/python-356/ We now return you to your pitched debate already in progress, //arry/

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel August 2018