John Paul Adrian Glaubitz added the comment:
I think there is one productive result of this discussion which is this patch
by Jessica Clark which gets rid of architecture-specific alignment code:
> https://github.com/python/cpython/pull/24624
Unfortunately, it has not seen any posit
John Paul Adrian Glaubitz added the comment:
> This thread is an excellent example why ignoring platforms comes at a cost.
> It will only get worse when are going to introduce platform and architecture
> specific code for optimizations and features.
Which is purely hyp
John Paul Adrian Glaubitz added the comment:
> So IMO it's fine to remove the support.
You are not removing "support". You're just disallowing users to use the Python
interpreter - which works perfectly fine on all architectures we have in
current and previous releases - on D
John Paul Adrian Glaubitz added the comment:
> The guidelines for platform support are explained in PEP 11
> (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't
> support platforms unless we have maintainers and CI (builtbots) in place for
> the platform
John Paul Adrian Glaubitz added the comment:
> Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's
> multilib support in a similar manner that I've mentioned about RHEL7?
I work at SUSE. I looked at the internal build system. Debian also still build
s390 mu
John Paul Adrian Glaubitz added the comment:
> What is the use case or benefit of building Python for 32-bit rather than
> 64-bit?
That's not really the question. The question is whether an upstream project
should prevent downstreams from using unsupported target configurations and I
John Paul Adrian Glaubitz added the comment:
> To get a platform supported by Python, we also need a volunteer to fix issues
> specific to the 31 bit s390 platform: see PEP 11.
You do not need to support every platform. Just allow your users to use them.
If something breaks down
John Paul Adrian Glaubitz added the comment:
I'm a Debian Developer and maintainer for multiple Debian Ports architectures.
Please don't remove support for Alpha, HPPA, m68k, ia64, PowerPC, SuperH, SPARC
as we're still maintaining these in Debian.
Here are the latest build results
John Paul Adrian Glaubitz added the comment:
And, FWIW, I generally don't quite understand what the problem with old triplet
definitions in configure.ac are. I assume they don't hurt anyone, do they?
You never know what usecases your users have and as long as a code snippet
doesn't
John Paul Adrian Glaubitz added the comment:
That's an argument I have personally never heard before and I have been dealing
with a lot of architecture support in many packages.
FWIW, lots of upstream projects have targets which are officially supported and
others which
John Paul Adrian Glaubitz added the comment:
s390 is a 31-bit platform, not a 32-bit platform.
I also don't see what this change achieves other than making the use of Python
3.10 on s390 harder.
It's not like the removal of support for non-threaded builds which actually
saved quite some
John Paul Adrian Glaubitz added the comment:
> I want to make it obvious that the platform has been dropped half a decade
> ago.
That's a political statement, not a technical one.
The change has zero functional impact on the other targets. It just makes the
use of Python in a pot
John Paul Adrian Glaubitz added the comment:
> I opened this ticket after a user told me that they grepped the source code
> of Python, found the string "s390", and concluded that s390 is still
> supported by us.
Because one user was surprised by a few lines in configure
John Paul Adrian Glaubitz added the comment:
> Moving forward, s390 will be unambiguously unsupported as we cannot test
> against this platform. Unless we get a buildbot provided for this purpose,
> as well as somebody willing to fix broken builds on that buildbot long-term,
>
John Paul Adrian Glaubitz added the comment:
> "Move support of legacy platforms/architectures outside Python"
> https://mail.python.org/archives/list/python-...@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/
Motorola 68k isn't a 16-bit architecture, it's a 32-bit archit
John Paul Adrian Glaubitz added the comment:
Oh, and LLVM is currently gaining support M68k which you consider "legacy":
> https://reviews.llvm.org/D95315
It might be a good idea to do some research first before making su
John Paul Adrian Glaubitz added the comment:
> But I don't see the benefit of annoying and discouraging users who want to
> experiment with Python and with Linux on Z in 31 bit mode.
Fully agree.
> Yes, maintenance theoretically is a burden, but there have been no recent
> issu
John Paul Adrian Glaubitz added the comment:
I'm running into exactly this issue when using 'offlineimap' which is written
in Python.
--
nosy: +glaubitz
___
Python tracker
<https://bugs.python.org/issue43
John Paul Adrian Glaubitz added the comment:
Hi Serhiy!
> The simple fix is to add UnicodeEncodeError to "except LookupError". But
> there may be other places where we can get a similar error. They should be
> fixed too.
I would be very interested to test this as t
John Paul Adrian Glaubitz added the comment:
> Awesome, thanks! I'll give it a try later today or tomorrow.
I have applied the patch and the problem seems to have been fixed. \o/
--
___
Python tracker
<https://bugs.python.org/issu
John Paul Adrian Glaubitz added the comment:
Awesome, thanks! I'll give it a try later today or tomorrow.
--
___
Python tracker
<https://bugs.python.org/issue43
21 matches
Mail list logo
