| msg330657 - (view) |
Author: STINNER Victor (vstinner) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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". |
|
|