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/
