On 2/21/21 1:13 PM, Victor Stinner wrote: > In short, I propose to move maintenance of the legacy platforms/archs > outside Python: people are free to continue support them as patches.
> Concrete example: Christian Heimes proposed to drop support for 31-bit > s390 Linux: > https://bugs.python.org/issue43179 I'm not attached to s390. But I doubt that the proposed patch lowers any "maintenance burden". https://github.com/python/cpython/pull/24534.diff touches a few files - configure.ac: PLATFORM_TRIPLET is undefined with your patch, changing the extension suffix. I don't think that maintaining such a delta outside the Python tree would be good practice. I am committed to maintain these definitions, and would like to ask not to remove *any* of these. These definitions come from https://wiki.debian.org/Multiarch/Tuples. - Modules/_ctypes/libffi_osx/ffi.c: Removing a macro usage in a file specific to MacOS X. Removal doesn't help, otherwise might create a patch conflict, if the MacOS X maintainers should ever decide to pull in a new libffi upstream version. - Lib/test/test_sysconfig.py: Doesn't simplify the code, just makes a bit more unfriendly. I became curious about a s390 build, and checked it with a GCC multilib build as available on at least Debian, OpenSuse, RHEL and Ubuntu. Builds fine with CC="gcc -m31" CXX="g++ -m31" ./configure && make && make test. No test failures, although I didn't build all extensions using externals libs. Funny thing, your proposed patch doesn't make any difference in the test results, so I'm not sure why you spent any volunteer time on that patch. With the threat^Wannouncement in issue 43179 to do similar removals for alpha, hppa and m68k, you'll likely step onto more toes, and again not removing any burden. > The lack of clear definition on how a platform is supported or not > confuses users who consider that their favorite platform/arch is > supported, whereas core developers don't want to support it since it > would be too much work. If a platform stops working, fine. Actively breaking a platform in some form: Not ok from my point of view. Python still is ubiquitous on almost all platforms (linux and non-linux ones), and can be built with mostly generic dependencies. Maybe libffi is an exception, however even these maintainers didn't remove s390 support (https://sourceware.org/libffi/). And I was very happy to build Python on a proprietary *nix platform five years ago, and having a working Python. > In fact, the PEP 11 has clear and explicit rules: > https://www.python.org/dev/peps/pep-0011/#supporting-platforms PEP 11 is not fit for that. You're not trying to remove support for the Linux platform, you're addressing a specific architecture. Maybe PEP 11 should be updated. As seen with S390, there's not much architecture specific code. If I see issues on the Linux platform for different architectures, these usually are: (1) 32bit vs 64bit (2) big endian vs. little endian (3) architecture specific alignment requirements, sometimes resulting in degraded performance on unaligned accesses, sometimes in bus errors when running 32bit code on 64 kernels. Looking at https://pythondev.readthedocs.io/platforms.html (yes, that gets the platform/architecture distinction right), - (1) and (2) are covered as "well supported" platforms, although having just x86* might lead to some x86-isms. - (1), (2) and (3) are covered as "best effort support" with aarch64 (64/LE), powerpc64le (64/LE), s390x (64/BE), and arm-linux-gnueabi* as 32/LE having bus errors on unaligned accesses with 64bit kernels. Unless CPython stops supporting these platforms above, I don't see little value of removing that tiny amount of architecture specific code. Document what is supported, be inclusive about anything else. Don't make a distinction yet between legacy and upcoming new architectures. Apparently the cryptography project made the decision to rely on a build tool which is not ubiquitously available anymore. If CPython sees the need for such restrictions in the future, I'd like to propose to use the same deprecation process for modules/functions, e.g. if a new non-ubiquitous tool X is needed to build/run, announce it for 3.10, and only make use of it in 3.11. Matthias > Example: 16-bit m68k no, it's a 32bit platform with extra alignment requirements. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YWRUGIA7XGRP6NABB3JEV552OSL6O52G/ Code of Conduct: http://python.org/psf/codeofconduct/
