Python-Dev February 2019

python-dev@python.org

86 participants
50 discussions

Another update for PEP 394 -- The "python" Command on Unix-Like Systems
by Petr Viktorin 01 Mar '19

01 Mar '19

PEP 394 says: > This recommendation will be periodically reviewed over the next few > years, and updated when the core development team judges it > appropriate. As a point of reference, regular maintenance releases > for the Python 2.7 series will continue until at least 2020. I think it's time for another review. I'm especially worried about the implication of these: - If the `python` command is installed, it should invoke the same version of Python as the `python2` command - scripts that are deliberately written to be source compatible with both Python 2.x and 3.x [...] may continue to use `python` on their shebang line. So, to support scripts that adhere to the recommendation, Python 2 needs to be installed :( Please see this PR for details and a suggested change: https://github.com/python/peps/pull/893

25 64

before I open an issue re: posix.stat and/or os.stat
by Michael 01 Mar '19

01 Mar '19

My focus is AIX - and I believe I found a bug in AIX include files in 64-bit mode. I'll take that up with IBM and AIX support. However, this issue might also be valid in Python3. The following is from Centos, not AIX Python 2.7.5 (default, Jul 13 2018, 13:06:57) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxsize 9223372036854775807 >>> import posix >>> posix.stat("/tmp/xxx") posix.stat_result(st_mode=33188, st_ino=33925869, st_dev=64768L, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1550742595, st_mtime=1550742595, st_ctime=1550742595) >>> st=posix.stat("/tmp/xxx") >>> dev=st.st_dev >>> min=posix.minor(dev) >>> maj=posix.major(dev) >>> min,max (0, <built-in function max>) >>> min 0 >>> max <built-in function max> >>> maj 253 >>> posix.minor(dev) 0 >>> posix.major(655536) 2560 >>> posix.major(65536) 256 >>> posix.major(256) 1 >>> import os >>> os.major(256) 1 >>> In AIX - 64-bit mode Python 3.8.0a1+ (heads/master:e7a4bb554e, Feb 20 2019, 18:40:08) [C] on aix7 Type "help", "copyright", "credits" or "license" for more information. >>> import sys,os,posix >>> sys.maxsize 9223372036854775807 >>> posix.major(256) 0 >>> posix.major(65536) 1 >>> posix.stat("/tmp/xxx") os.stat_result(st_mode=33188, st_ino=12, st_dev=-9223371993905102841, st_nlink=1, st_uid=202, st_gid=1954, st_size=0, st_atime=1550690105, st_mtime=1550690105, st_ctime=1550690105) AIX 32-bit: root@x066:[/data/prj/python/git/python3-3.8.0.66]./python Python 3.8.0a1+ (heads/master:e7a4bb554e, Feb 19 2019, 11:22:56) [C] on aix6 Type "help", "copyright", "credits" or "license" for more information. >>> import os,sys,posix >>> sys.maxsize 2147483647 >>> posix.major(65536) 1 >>> posix.stat("/tmp/xxx") os.stat_result(st_mode=33188, st_ino=149, st_dev=655367, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1550743517, st_mtime=1550743517, st_ctime=1550743517) To make it easier to view: buildbot@x064:[/home/buildbot]cat osstat.c #include <sys/types.h> #include <sys/stat.h> #include <sys/sysmacros.h> #include <stdio.h> main() { dev_t dev; char *path = "/tmp/xxx"; struct stat st; int minor,major; lstat(path,&st); printf("size: %d\n", sizeof(st.st_dev)); dev = st.st_dev; minor = minor(dev); major = major(dev); printf("%016lx %ld %ld\n",dev,dev, (unsigned) dev); printf("%d,%d\n",major,minor); } buildbot@x064:[/home/buildbot]OBJECT_MODE=32 cc osstat.c -o osstat-32 && ./osstat-32 size: 4 00000000000a0007 655367 655367 10,7 And here is the AIX behavior (and bug - major() macro!) buildbot@x064:[/home/buildbot]OBJECT_MODE=64 cc osstat.c -o osstat-64 && ./osstat-64 size: 8 8000000a00000007 -9223371993905102841 7 0,7 The same on AIX 6 (above is AIX7) - and also with gcc: root@x068:[/data/prj]gcc -maix64 osstat.c -o osstat-64 && ./osstat-64 size: 8 8000000a00000007 -9223371993905102841 42949672967 0,7 root@x068:[/data/prj]gcc -maix32 osstat.c -o osstat-32 && ./osstat-32 size: 4 00000000000a0007 655367 0 10,7 root@x068:[/data/prj] So, the AIX 'bug' with the macro major() has been around for ages - but ALSO setting the MSB of the st_dev. +++++ Now my question: Will this continue to be enough space - i.e., is the Dev size going to be enough? +2042 #ifdef MS_WINDOWS +2043 PyStructSequence_SET_ITEM(v, 2, PyLong_FromUnsignedLong(st->st_dev)); +2044 #else +2045 PyStructSequence_SET_ITEM(v, 2, _PyLong_FromDev(st->st_dev)); +2046 #endif +711 #define _PyLong_FromDev PyLong_FromLongLong It seems so - however, Is there something such as PyUnsignedLong and is that large enough for a "long long"? and if it exists, would that make the value positive (for the first test). posix.major and os.major will need to mask away the MSB and posix.makedev and os.makedev will need to add it back. OR - do I need to make the PyStat values "the same" in both 32-bit and 64-bit? Puzzled on what you think is the correct approach. Michael

3 2

[RELEASE] Python 3.8.0a1 is now available for testing
by Łukasz Langa 28 Feb '19

28 Feb '19

I packaged another release. Go get it here: https://www.python.org/downloads/release/python-380a2/ Python 3.8.0a2 is the second of four planned alpha releases of Python 3.8, the next feature release of Python. During the alpha phase, Python 3.8 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.8.0a3, is planned for 2019-03-25. This time around the stable buildbots were a bit less green than they should have. This early in the cycle, I didn't postpone the release and I didn't use the revert hammer. But soon enough, I will. Let's make sure future changes keep the buildbots happy. - Ł

4 4

datetime.timedelta total_microseconds
by Richard Belleville 28 Feb '19

28 Feb '19

In a recent code review, the following snippet was called out as reinventing the wheel: _MICROSECONDS_PER_SECOND = 1000000 def _timedelta_to_microseconds(delta): return int(delta.total_seconds() * _MICROSECONDS_PER_SECOND) The reviewer thought that there must already exist a standard library function that fulfills this functionality. After we had both satisfied ourselves that we hadn't simply missed something in the documentation, we decided that we had better raise the issue with a wider audience. Does this functionality already exist within the standard library? If not, would a datetime.timedelta.total_microseconds function be a reasonable addition? I would be happy to submit a patch for such a thing. Richard Belleville

12 27

Can I get a review for PR 10437?
by Kevin Adler 28 Feb '19

28 Feb '19

2 1

Proposed dates for Python 3.4.10 and Python 3.5.7
by Larry Hastings 27 Feb '19

27 Feb '19

Howdy howdy! It's time to make the next bugfix release of 3.5--and the /final/ release /ever/ of Python 3.4. Here's the schedule I propose: 3.4.10rc1 and 3.5.7rc1 - Saturday March 2 2019 3.4.10 final and 3.5.7 final - Saturday March 16 2019 What's going in these releases? Not much. I have two outstanding PRs against 3.5: bpo-33127 GH-10994: Compatibility patch for LibreSSL 2.7.0 bpo-34623 GH-9933: XML_SetHashSalt in _elementtree and one PR against 3.4: bpo-34623 GH-9953: Use XML_SetHashSalt in _elementtree I expect to merge all three of those, I just need to get around to it. There's one more recent security fix (bpo-35746, GH-11569) that I want in these releases that still needs backporting. And that's the entire list. bpo-34623 is the only current release blocker for either 3.4 or 3.5--I'm not aware of anything else in the pipeline. If you have anything you think needs to go into the next 3.5, or the final 3.4, and it's /not/ listed above, please either file a GitHub PR, file a release-blocker bug on bpo, or email me directly. Good night sweet Python 3.4, and flights of angels sing thee to thy rest! //arry/

3 4

Announcing: signups are open for the 2019 Python Language Summit
by Łukasz Langa 27 Feb '19

27 Feb '19

The Python Language Summit is an event for the developers of Python implementations (CPython, PyPy, Jython, and so on) to share information, discuss our shared problems, and — hopefully — solve them. These issues might be related to the language itself, the standard library, the development process, status of Python 3.8 (or plans for 3.9), the documentation, packaging, the website, et cetera. The Summit focuses on discussion more than on presentations. If you’d like to attend **and actively participate** in the discussions during the Language Summit, please fill in this form by March 21st 2019: https://goo.gl/forms/pexfOGDjpV0BWMer2 We will be evaluating all applications and confirm your attendance by April 15th. Note: **your attendance is not confirmed** until you heard back from us. You don't need to be registered for PyCon in order to attend the summit. One of the goals of the Language Summit is to speed up the discussions and decision making process. Communication over Discourse (or mailing lists!) is generally more time consuming. As part of efforts to make this event more open and less mysterious, we are not requiring invitations by core developers anymore. However, please understand that we will have to be selective as space and time are limited. In particular, we are prioritizing active core contributors, as well as those who we believe will be able to improve the quality of the discussions at the event and bring a more diverse perspective to core Python developers. As for other changes this year, A. Jesse Jiryu Davis will be covering the event and will post a detailed write up on the official blog of the PSF shortly after the conference. We hope to see you at the Summit! - Mariatta and Łukasz PS. If you have any questions, the Users section of our Discourse instance (https://discuss.python.org/c/users) is the best place to ask. For private communication, write to mariatta(a)python.org and/or lukasz(a)python.org.

1 1

OpenSSL 1.1.1 update for 3.7/3.8
by Christian Heimes 26 Feb '19

26 Feb '19

Hi, today's OpenSSL release of 1.0.2r and 1.1.1b reminded me of OpenSSL's release strategy [1]. OpenSSL 1.0.2 will reach EOL on 2019-12-31, 1.1.0 will reach EOL on 2019-09-11 (one year after release of OpenSSL 1.1.1). First the good news: There is no need to take any action for 2.7 to 3.6. As of today, Python 2.7, 3.5, and 3.6 are using OpenSSL 1.0.2. Python 3.6.8 (2018-12-24) and 3.5.5 (2018-02-05) were the last regular update with binary packages. 3.5.6 is a source-only security release. 3.6.9 will be the first source-only security release of the 3.6 series. Python 2.7 will reach EOL just a day after OpenSSL 1.0.2 reaches EOL. IMHO it's fine to ship the last 2.7 build with an OpenSSL version that was EOLed just 24h earlier. Python 3.7 and master (3.8) are affected. As of now, both branches use OpenSSL 1.1.0 and must be updated to 1.1.1 soonish. Ned has scheduled 3.7.3 release for 2019-03-25. That's still well within the release schedule for 1.1.0. I suggest that we update to 1.1.1 directly after the release of Python 3.7.3 and target 3.7.4 as first builds with TLS 1.3 support. That gives Victor, Steve, and me enough time to sort out the remaining issues. In worst case we could revert the update and postpone the update to 3.7.5. Or we disable TLS 1.3 support by default in Mac and Windows builds. Christian [1] https://www.openssl.org/policies/releasestrat.html

2 3

New member
by Aratz Manterola Lasa 26 Feb '19

26 Feb '19

I do not know if I should be doing this, maybe I have been cheated, but this is my introduction: Hello, my name is Aratz, I am a Computer Engineering Bachelor's (not, not science) student on my 3rd grade. I love Python's gramatic efficiency, but most of all, how much I learn thanks to its community. I want to learn more, and if it is possible from the best ones. So... I ended up here. Thanks for your attention.

1 0

Asking for reversion
by Antoine Pitrou 25 Feb '19

25 Feb '19

Hello, I'd like to ask for the reversion of the changes done in https://github.com/python/cpython/pull/11664 The reason is simple: the PR isn't complete, it lacks docs and tests. It also didn't pass any review (this was pointed by Ronald), even though it adds 1300 lines of code. No programmer is perfect, so it's statistically likely that the PR is defective. With git, forks and branches, we definitely don't need to commit unfinished PRs to the main repo. It's perfectly fine to maintain some non-trivial piece of work in a separate fork. People do it on a regular basis (for example I have currently two such long-lived branches: one for PEP 556 and one for PEP 574). Also, this is not the first time this happened. Another multiprocessing PR was merged some years ago without any docs or tests: https://bugs.python.org/issue28053 Today that work /still/ lacks docs or tests, and there is a suspicion that it doesn't work as intended (see issue comments). It's probably too late to revert it, but it's definitely a slippery slope. Regards Antoine.

13 30

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev February 2019