classification
Title: Modernize Lib/platform.py code
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, lemburg, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2018-11-29 01:42 by vstinner, last changed 2018-12-14 12:15 by vstinner. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 10786 merged vstinner, 2018-11-29 01:44
PR 10892 merged vstinner, 2018-12-04 14:06
PR 10959 merged vstinner, 2018-12-05 21:53
PR 11130 merged vstinner, 2018-12-12 16:55
Messages (15)
msg330657 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-11-29 01:42
Lib/platform.py still contains code to support Python 2.3. It's maybe time to modernize it.

platform imports subprocess since commit fc990e942fb55be78e8352f4913749e91cac381d. The two calls to os.popen() can now be replaced with subprocess.Popen.
msg330718 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2018-11-29 19:44
It's because the module was originally kept compatible with Python 1.5.2: https://www.python.org/dev/peps/pep-0291/#backward-compatible-packages-modules-and-tools
msg330727 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-11-29 21:54
While we are here, look at other outdated code:

* Top-imported warnings is not used.
* struct.calcsize('P') is always success.
* plistlib is always available.

Should we keep compatibility with 2.7?
msg330729 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-11-29 21:59
> Should we keep compatibility with 2.7?

I don't think that the master branch (Python 3.8) has to be compatible with Python 2.7.
msg330731 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2018-11-29 22:07
Please keep Python 2.7 compatibility. It should be possible to copy the module back into Python 2.7 and use it there. This is not hard to do and allows it to fulfill its purpose as platform detection module even while part of the stdlib.
msg330733 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-11-29 22:14
> Please keep Python 2.7 compatibility. It should be possible to copy the module back into Python 2.7 and use it there.

I don't understand why someone would like to copy Lib/platform.py from the master branch to Python 2.7? Python 2.7 already provides the platform module, it's part of its standard library.

platform.linux_distribution() function has been removed from master, so you cannot simply copy platform.py from master and use it in Python 2.7: it has a different API.
msg330735 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2018-11-29 22:53
Ok, let me add some history here:

When I created the platform module it was clear that this would be
a module which will frequently need updates, since platforms evolve
faster than Python does.

I had developed this with a larger number of contributors outside
the stdlib for a while and then there was a request to add it to the
stdlib.

Now in order to keep the module more or less up-to-date, it still
required regular updates, so the plan was to have it updated in the
current versions of Python, but allow it to be used in older Python
versions as well. That was the compromise to have it in the stdlib
and not external. Otherwise, I would have not added it to the stdlib.

This is why it has a special status and keep backwards compatibility
much longer than other code in the stdlib.

This worked quite well, but for some systems such as the Linux
distros, it was impossible to keep up with the development in that
mode. Well, actually, there were multiple reasons why this part
failed: 1. Linux distros didn't not have a standard when I added
the code, 2. Then some distros started two or three different ones,
3. Distros started to use multiple standards with conflicting data,
4. New distros became popular more often than we could update the
code.

That's why I was fine with removing the code again and leaving this
part to a PyPI package.

Does it make more sense now ?
msg330737 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-11-30 00:02
> Now in order to keep the module more or less up-to-date, it still
> required regular updates, so the plan was to have it updated in the
> current versions of Python, but allow it to be used in older Python
> versions as well. That was the compromise to have it in the stdlib
> and not external. Otherwise, I would have not added it to the stdlib.

I don't understand if you are describing the current status or the history here. Do you know users who don't use platform form the stdlib, but use a more recent copy?

These users cannot get a more recent version of Python?

When you talk about copying Lib/platform.py from master to Python 2.7, are you talking about the ability to copy platform.py from master into an application to get a more recent version on Python 2.7? If yes, I don't understand how you plan to add back the linux_distribution() feature?

Sorry, I'm still lost :-(
msg330943 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-03 13:00
Another issue with Python 2 compatibility (I addition to platform.dist() removal) of Lib/platform.py from master: it uses re.ASCII which doesn't exist in Python 2.7.
msg331061 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-04 16:18
New changeset b8e689a6e8134e88f857a55e50b6a4977967e385 by Victor Stinner in branch 'master':
bpo-35346, platform: import subprocess in _syscmd_file() (GH-10892)
https://github.com/python/cpython/commit/b8e689a6e8134e88f857a55e50b6a4977967e385
msg331285 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-07 10:10
New changeset 3a521f0b6167628f975c773b56c7daf8d33d6f40 by Victor Stinner in branch 'master':
bpo-35346, platform: replace os.popen() with subprocess (GH-10786)
https://github.com/python/cpython/commit/3a521f0b6167628f975c773b56c7daf8d33d6f40
msg331709 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-12 16:48
New changeset b0e0877629e3df4bc3042fd424e96f197b2e9fa4 by Victor Stinner in branch 'master':
bpo-35346: Drop Mac OS 9 support from platform (GH-10959)
https://github.com/python/cpython/commit/b0e0877629e3df4bc3042fd424e96f197b2e9fa4
msg331710 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-12 16:57
> Top-imported warnings is not used.

Fixed by commit b8e689a6e8134e88f857a55e50b6a4977967e385.

> struct.calcsize('P') is always success.

I wrote PR 11130 for that.

Note: struct.calcsize('P') always works on Python 2.7 as well.

> plistlib is always available.

I don't know this module. This module imports many other modules like xml.parsers.expat. I don't think that the try/except ImportError hurts. Feel free to propose a PR if you want.
msg331813 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-14 12:14
New changeset 4aa917c5feaec07a6f6db87b34185ab6180e20ee by Victor Stinner in branch 'master':
bpo-35346: Cleanup platform.architecture() (GH-11130)
https://github.com/python/cpython/commit/4aa917c5feaec07a6f6db87b34185ab6180e20ee
msg331815 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-12-14 12:15
I close the issue. I made that changes that I wanted :-)

Serhiy: reopen the issue or open a new one if you want to remove the try/except ImportError around "import plistlib".
History
Date User Action Args
2018-12-14 12:15:57vstinnersetstatus: open -> closed
messages: + msg331815

dependencies: - Problems with handling the file command output in platform.architecture()
resolution: fixed
stage: patch review -> resolved
2018-12-14 12:14:12vstinnersetmessages: + msg331813
2018-12-12 16:57:36vstinnersetmessages: + msg331710
2018-12-12 16:55:05vstinnersetpull_requests: + pull_request10361
2018-12-12 16:48:12vstinnersetmessages: + msg331709
2018-12-07 10:10:38vstinnersetmessages: + msg331285
2018-12-05 21:53:44vstinnersetpull_requests: + pull_request10205
2018-12-04 16:18:15vstinnersetmessages: + msg331061
2018-12-04 14:06:05vstinnersetpull_requests: + pull_request10131
2018-12-03 13:00:34vstinnersetmessages: + msg330943
2018-11-30 00:02:26vstinnersetmessages: + msg330737
2018-11-29 22:53:50lemburgsetmessages: + msg330735
2018-11-29 22:14:25vstinnersetmessages: + msg330733
2018-11-29 22:07:08lemburgsetnosy: + lemburg
messages: + msg330731
2018-11-29 21:59:21vstinnersetmessages: + msg330729
2018-11-29 21:54:39serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg330727
2018-11-29 19:44:57brett.cannonsetnosy: + brett.cannon
messages: + msg330718
2018-11-29 12:34:03serhiy.storchakasetdependencies: + Problems with handling the file command output in platform.architecture()
2018-11-29 01:44:03vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request10030
2018-11-29 01:42:39vstinnercreate