python-devel September 2016

python-devel@lists.fedoraproject.org

15 participants
11 discussions

Python 3.6 and blocking-by-default os.urandom()
by Nick Coghlan 04 Jan '17

04 Jan '17

Hi folks, The long discussions upstream regarding the default behaviour of Python's os.urandom() API in Python 3.6 have come to an end, with Guido opting to make os.urandom() block implicitly waiting for the system RNG to be ready, even on Linux (where /dev/urandom doesn't do that). While I can see his point from a cross-platform language runtime design perspective, I'm still not sure it's the right answer for the Fedora system Python, as it doesn't play nice with ABRT, and goes against Ted T'so's decision to keep /dev/urandom non-blocking at the kernel level (risking confusion for folks that are Linux developers & operators first, and Pythonistas second). If "os.urandom() was called before system RNG is ready" throws an uncaught BlockingIOError, then we'll get a nice ABRT-friendly Python stack trace for people to debug (and perhaps figure out their VM entropy pool isn't being seeded properly, or their ARM hardware design needs a better source of entropy). By contrast, if it just blocks, then folks will be faced with a system hang, which they'll need to trace back to CPython being blocked on a kernel getrandom() call, and then infer from that that the system RNG isn't ready (for whatever reason), and they should probably do something about that. Patching this behaviour should be relatively straightforward - Python 3.5 currently makes this call in non-blocking mode and falls back to reading /dev/urandom directly in that case, so we'd just be forward porting the same logic to 3.6 and raising an exception instead of falling back to the file descriptor. Accordingly, what I propose we do is as follows: 1. Raise the concern in the F26 system-wide change proposal for migrating to Python 3.6 2. Apply the patch when the 3.6 beta releases are added to Fedora Rawhide 3. Decide whether or not to keep the patch based on ABRT results and other feedback on the Rawhide builds. Note that if the feedback on Rawhide shows that the change is helping people to find and diagnose VMs and hardware with improperly seeded entropy pools, that's a *good* thing: this proposed change is replacing Python 3.5's "/dev/urandom and os.urandom() may silently return statistically less-than-fully-random random numbers if the kernel entropy pool isn't seeded properly" with "os.urandom() will fail noisily in those cases, so you can either switch to the random module, or fix your entropy pool seeding". Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

4 9

Python SIG on-boarding issue
by Dhanesh B. Sabane 08 Dec '16

08 Dec '16

CommOps is currently working on the Python SIG On-Boarding ticket [1] and one of the tasks we have identified is re-writing the Python SIG wiki page to make it more beginner-friendly. I was assigned with this particular task which is now complete [2] [3]. We received some feedback from mhroncok today during the CommOps meeting and following points were discussed: 1. Splitting Python SIG in two FAS groups: 1.1 *python-sig* for newcomers and interested members who hang out and help with Python on Fedora 1.2 *python-packagers* for proven members of the community / packagers who will also receive security-related bugs. Promising members from *python-sig* group can be promoted to *python-packagers* given that they have contributed to the package's git. 2. Python Features section on the wiki page needs some love. 3. Targeting specific information for newcomers to include in their self-introductions that would be helpful for SIG members to know where someone fits in the Python community and what their expertise is. We would like to hear your feedback on the draft and also on the aforementioned points. Everyone is welcome to leave a comment on the ticket[1]. [1] https://pagure.io/fedora-commops/issue/84 [2] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python [3] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python/Join --- Dhanesh B. Sabane

6 11

python34 for epel6 ?
by Tim Orling 17 Oct '16

17 Oct '16

I came across a need for python34 on epel6. I did not see any BZ for it. Are there significant issues with packaging python34 for epel6? or just nobody wanted to do it yet? Cheers. --Tim P.S Thank you for python34 on epel7. worked like a charm. P.P.S. I realize rh-python34 is available on RHSCL, but it didn't seem to support "python3" in scripts...

3 8

pytest 3.0 in rawhide
by Thomas Moschny 30 Sep '16

30 Sep '16

Hi, this is a heads-up about the pytest update to version 3.0.3 that just hit rawhide. A number of incompatible changes were made in 3.0.0 compared to 2.9.2. See http://doc.pytest.org/en/latest/changelog.html for the full list of changes and new features. If you got this email directly, then your package (SRPM) depends on pytest. Please check, whether it builds and works with the new pytest release. This especially holds for the pytest plugins, some of which definitively need to be updated to support pytest 3.0. Here's the list of packages that (according to dnf repoquery) build-depend on pytest: copr-frontend copr-keygen freeipa python-astropy python-coveralls python-django-pytest python-docopt python-gabbi python-lib389 python-pytest-cache python-pytest-capturelog python-pytest-cov python-pytest-mock python-pytest-multihost python-pytest-pep8 python-pytest-runner python-pytest-sourceorder python-pytest-spec python-pytest-testmon python-pytest-timeout python-pytest-watch python-pytest-xdist python3-pytest-asyncio Thanks, Thomas

1 0

Fwd: [fpc] #650: Suggested Change for Python Guidelines about Alternate Python Interpreters
by Miro Hrončok 30 Sep '16

30 Sep '16

-------- Forwarded Message -------- Subject: [fpc] #650: Suggested Change for Python Guidelines about Alternate Python Interpreters Date: Fri, 30 Sep 2016 10:47:07 -0000 From: fpc <trac(a)fedorahosted.org> Reply-To: nobody(a)fedoraproject.org #650: Suggested Change for Python Guidelines about Alternate Python Interpreters ------------------------------+------------------- Reporter: churchyard | Owner: Status: new | Priority: normal Component: Guideline Draft | Keywords: Blocked By: | Blocking: ------------------------------+------------------- Whole page: https://fedoraproject.org/wiki/User:Churchyard/AlternatePythons#Alternate_P… Diff: https://fedoraproject.org/w/index.php?title=User%3AChurchyard%2FAlternatePy… Quote: == Alternate Python versions == There are alternate Python versions packaged in Fedora, such as python26, python33, python34, python35 and possibly more in the future. No package shall ever ''BuildRequire'' or ''Require'' those packages (or their ''Provides''), as those packages are only intended for developers for testing purposes and may have security issues. Those packages may only be ''Recommended'' or ''Suggested'' by tools intended for testing Python code on various interpreters, such as python-tox. -- Ticket URL: <https://fedorahosted.org/fpc/ticket/650> fpc <https://fedoraproject.org/wiki/Packaging:Committee> Fedora Packages Collection Task Tracking

1 0

Review swap
by Germano Massullo 27 Sep '16

27 Sep '16

Hi everybody, I would need to make a review swap. My review request is python-django-jsonfield - A reusable Django field that allows you to store validated JSON in your model https://bugzilla.redhat.com/show_bug.cgi?id=1375222#c6 Today I fixed all the problems and runned fedora-review to see if there was any warning. It seemed that everything was fine. Thank you and have a nice day

1 1

Python (3) packaging for EPEL 7: hddfancontrol
by Ben Rosser 23 Sep '16

23 Sep '16

Hello, I just packaged and built hddfancontrol ( https://github.com/desbma/hddfancontrol) for Fedora, which is written in Python 3. I'd like to get this built for EPEL-- the machine that I want to run it on is actually a CentOS 7 box. However, there's a problem: it depends on python-daemon, which only gained python3 support in version 2.0 The EPEL package provides version 1.6. So, obviously I can build this in a Copr if I really want, alongside an updated python-daemon package. However, there is a fork of python-daemon 1.x, python-daemon-3K (https://pypi.python.org/pypi/python-daemon-3K/1.5.8), that supports Python 3. Upstream hddfancontrol actually depends on this version of python-daemon, so for Fedora I had to patch it to use python-daemon 2.0 instead. So perhaps it would make sense to package python-daemon-3K just for EPEL and have it provide python3*-daemon? Is that a reasonable course of action here? Any other suggestions besides just using Copr? Thanks in advance for any guidance, Ben Rosser

2 1

Question about Python applications / web applications
by Germano Massullo 19 Sep '16

19 Sep '16

Hi, I have a question about Python applications and web applications. I remember (but I am not 100% sure) that I have been told that if the application / web application runs on Fedora, the packager will just have to make the Python3 version and call it python-foo. No Python 2 version has to be built. On the opposite site, for EPEL <= 7, Python 2 is the only choice. Am I right or not? Have a nice day

3 6

PEP: Distributing a Subset of the Standard Library
by Tomas Orsava 08 Sep '16

08 Sep '16

Hi! I'm currently writing a PEP titled "Distributing a Subset of the Standard Library" to standardize and hopefully improve the behavior of Python without the its full standard library. This is relevant to Fedora, as we exclude several standard library modules into separate optional packages (e.g. python3-tkinter). I have a draft of the first two sections: Motivation and Specification. https://fedora-python.github.io/pep-drafts/pep-A.html The source can be found here: https://github.com/fedora-python/pep-drafts All the best, Tomas Orsava

4 9

fedoralovespython.org
by Petr Viktorin 07 Sep '16

07 Sep '16

Hello! Some time ago, at Flock, a couple of us had the idea to better promote Fedora's Python story. Currently we have the "Python Features" section on the Wiki [0][1], but the target audience there is the Python SIG itself – people who work on the integration, not those who "just" use Python. There's also the Python Brochure [2], which looks quite nice but the content is ... well, not very useful for developers. In my experience (with portingdb), a bit of HTML and CSS can go a long way towards getting people interested. So we started writing down some developer-focused Python talking points: https://fedoralovespython.org/ And here's a preview with points that aren't ready for prime time yet: https://fedoralovespython.org/__future__/ The points there are just headlines with links to more information – mostly to the Fedora Developer Portal. A lot of the effort in the "fedoralovespython.org project" should go into improving the Developer Portal content [3][4][5]. The guides there can help people get started, but should also help *us* check that getting started is as easy as it can be :) If you want to help out, the repo is public: https://github.com/fedora-python/fedoralovespython.org The page isn't publicly announced yet. Until it has some more content, please don't market it to people who wouldn't interested in it as a Python SIG project. [0] https://fedoraproject.org/wiki/SIGs/Python#Python_Features [1] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python#Python_Features [2] https://fedoraproject.org/wiki/Marketing/Python_brochure [3] https://github.com/developer-portal/content/pull/159 [4] https://github.com/developer-portal/content/pull/156 [5] https://github.com/developer-portal/content/pull/158 -- Petr Viktorin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel September 2016