[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
(Since my first reply here somehow got lost, I'm posting this again). Rust doesn't prevent anyone from building Tier 2 or Tier 3 targets. There is no limitation for "legacy" or "deprecated" targets. Any target can be built and any target can be selected by the Rust compiler for cross-compliation. So, if you want to mimic the behavior of the Rust compiler, you would obviously not guard any architectures or platforms in configure.ac. I am objecting this change as it does not reduce code complexity (on the contrary) and only causes more maintenance burden for downstream distributions. Thanks, Adrian ___ 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/EEFDCMVRNHDBUHRUXOC4TEFFYA6NETPB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms. There is no separate configure guard. All platforms that Rust can build for, are always enabled by default. No one in Rust keeps anyone from cross-compiling code for sparc64 or powerpcspe, for example. So if you want to copy Rust's mechanism, you should just leave it as is and not claim that users are being confused because "m68k" shows up in configure.ac. Adrian ___ 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/5DXDCNS4C3JS43JGLIKYTRNV6AAQE5TD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
There are zero technical reasons for what you are planning here.
You are inflating a few lines of autoconf into a "platform support", so you
have a reason to justify adding multiple lines of extra autoconf codes to make
life for downstream distributions harder.
I could understand the maintenance burden argument if there was actually any
maintenance burden, there isn't.
The thing is you made assumptions about how downstream distributions use Python
without doing some research first ("16-bit m68k-linux"). I have explained that
these assumptions are not correct and that downstreams do actively use Python
in ways that upstream no longer considers supported, yet you want to make
changes to make everything for downstreams harder.
I have not seen any other upstream project that is so bothered about a few
lines of autoconf code. All other upstream projects I have worked with, be it
Rust, OpenJDK, abseil-cpp and so on: None of them had problems when I sent
patches to improve the code on more architectures.
But in Python, it's suddenly a problem and you start long discussions about a
few lines of autoconf code that pose zero maintenance burden.
I absolutely don't get it.
Adrian
___
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/RD75H2KJQS2YC5H6P75PNGEDZ5UNCTHQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
> The main thing from a project maintenance perspective is for platforms to not become a burden to other code maintainers. PRs need to be reviewed. Every #if/#endif in code is a cognitive burden. So being a minor platform can come with unexpected breakages that need fixing due to other changes made in the codebase that did not pay attention to the platform. As we cannot expect everyone working on code to care about anything beyond the tier-1 fully supported platforms, buildbot or not. Yes, but all this doesn't apply here. We're literally talking about a few lines of autoconf and preprocessor defines [1]. In fact, the change to remove "s390 support" (in quotes because these few lines don't really can be considered platform-specific code), introduces more lines than it removes because of the comments. Adrian > [1] https://github.com/python/cpython/pull/24534/files ___ 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/OFBMDNWADAULXH7IS4ABGNSAYF4KFMI7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On 2/22/21 12:30 PM, Victor Stinner wrote:
> On Mon, Feb 22, 2021 at 8:19 AM wrote:
>> There are zero technical reasons for what you are planning here.
>
> Multiple core developers explained how it's a maintenance burden. It
> has been explained in multiple different ways.
Well, that doesn't mean these statements are correct.
Please don't assume that the people you are talking to are inexperienced
developers, we aren't. Downstream distribution maintainers certainly have
enough experience with project maintenance to be able to asses whether
your claims are valid or not.
>> You are inflating a few lines of autoconf into a "platform support", so you
>> have a reason to justify adding multiple lines of extra autoconf codes to
>> make
>> life for downstream distributions harder.
>
> "Making life harder" sounds to me like oh, maybe supporting one
> additional platform is not free and comes with a cost. This cost is
> something called the "maintenance burden".
Please explain to me how guarding some platforms with *additional* lines
autoconf is helping to reduce maintenance burden for the upstream project.
> My question is if Python wants to pay this cost, or if we want
> transfering the maintenance burden to people who actually care about
> these legacy platforms and architectures.
>
> Your position is: Python must pay this price. My position is: Python should
> not.
No, my position is that such changes should have valid technical reasons
which is simply not the case. You're not helping your point if you are
basing your arguments on incorrect technical assumptions.
> Honestly, if it's just a few lines, it will be trivial for you to
> maintain a downstream patch and I'm not sure why we even need this
> conversation. If it's more than a few lines, well, again, we come back
> to the problem of the real maintenance burden.
This argument goes both ways. The code we are talking about here are
just a few lines of autoconf which are hardly touched during normal
development work. And the architecture-mapping you have in [1] is probably
not even needed (CC @jrtc27).
>> The thing is you made assumptions about how downstream distributions use
>> Python without doing some research first ("16-bit m68k-linux").
>
> I'm talking about 16-bit memory alignment which causes SIGBUS if it's
> not respected on m68k. For example, unicodeobject.c requires special
> code just for this arch:
>
> /*
> * Issue #17237: m68k is a bit different from most architectures in
> * that objects do not use "natural alignment" - for example, int and
> * long are only aligned at 2-byte boundaries. Therefore the assert()
> * won't work; also, tests have shown that skipping the "optimised
> * version" will even speed up m68k.
> */
> #if !defined(__m68k__)
> (...)
>
> Such issue is hard to guess when you write code and usually only spot
> it while actually running the code on such architecture.
This is the only such place in the code where there is an extra section
for m68k that I could find. And the bug was fixed by Andreas Schwab [2],
so another downstream maintainer which was my point earlier in the discussion.
We downstreams care about the platform support, hence we keep it working.
Thanks,
Adrian
> [1]
> https://github.com/python/cpython/blob/63298930fb531ba2bb4f23bc3b915dbf1e17e9e1/configure.ac#L724
> [2]
> https://github.com/python/cpython/commit/8b0e98426dd0e1fde93715256413bc707759db6f
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
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/4OALXE4CUIFA4JGH3Y2BCLQ7WI4LR6U6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
Hello!
On 2/22/21 12:30 PM, Victor Stinner wrote:
>> The thing is you made assumptions about how downstream distributions use
>> Python without doing some research first ("16-bit m68k-linux").
>
> I'm talking about 16-bit memory alignment which causes SIGBUS if it's
> not respected on m68k. For example, unicodeobject.c requires special
> code just for this arch:
>
> /*
> * Issue #17237: m68k is a bit different from most architectures in
> * that objects do not use "natural alignment" - for example, int and
> * long are only aligned at 2-byte boundaries. Therefore the assert()
> * won't work; also, tests have shown that skipping the "optimised
> * version" will even speed up m68k.
> */
> #if !defined(__m68k__)
> (...)
>
> Such issue is hard to guess when you write code and usually only spot
> it while actually running the code on such architecture.
Just as a heads-up: There is a PR by Jessica Clarke now [1] which gets rid of
this
architecture-specific #ifdef. I think this is a good approach as it gets rid of
one
of your complaining points.
I have already verified that these changes don't break on 32-bit PowerPC,
64-bit SPARC
and, of course, M68k.
Thanks,
Adrian
> [1] https://github.com/python/cpython/pull/24624
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
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/TQVOGEZ3NXQP6PN5RTOG5IDBCGTIPAU5/
Code of Conduct: http://python.org/psf/codeofconduct/
