On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
> 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
On 22.02.2021 11:20, Michał Górny wrote:
On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
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.
Hello,
On Mon, 22 Feb 2021 09:20:46 +0100
Michał Górny wrote:
> On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
> > 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
Hello,
On Mon, 22 Feb 2021 10:44:19 +0100
Peter Otten <__pete...@web.de> wrote:
> On 21/02/2021 23:06, Terry Reedy wrote:
> > On 2/21/2021 12:04 PM, Paul Sokolovsky wrote:
> >
> >> Traceback (most recent call last):
> >> File "pseudoc_tool.py", line 91, in
> >> first_class_function_val
On Sun, Feb 21, 2021 at 8:57 PM Michał Górny wrote:
> > The checker serves two purposes:
> >
> > 1) It gives users an opportunity to provide full PEP 11 support
> > (buildbot, engineering time) for a platform.
>
> Does that mean that if someone offers to run the build bot for a minor
> platform an
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.
> You are inflating a few lines of autoconf into a "platform support", so
pybind11 is a famous C++ extension module for Python. Yes, the Python
C API is usable in C++ thanks to extern "C" { ... } being used in
headers.
Victor
On Sun, Feb 21, 2021 at 6:59 PM Dan Stromberg wrote:
>
>
> It looks like CPython remains 100% C, so clang becomes more attractive:
> https://st
IIRC I suggested earlier that buildsbots should be integrated into the PR workflow in order to make it the contributor's rather than a core
dev's burden to fix any breakages that result from their changes.
On 22.02.2021 14:20, Victor Stinner wrote:
On Sun, Feb 21, 2021 at 8:57 PM Michał Górny
On Mon, Feb 22, 2021 at 12:51 PM Ivan Pozdeev via Python-Dev
wrote:
> IIRC I suggested earlier that buildsbots should be integrated into the PR
> workflow in order to make it the contributor's rather than a core
> dev's burden to fix any breakages that result from their changes.
Some buildbot wo
On Mon, 2021-02-22 at 12:30 +0100, Victor Stinner wrote:
> On Mon, Feb 22, 2021 at 8:19 AM 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 c
On 2/21/21 9:24 PM, Gregory P. Smith wrote:
> On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes
> wrote:
>
>> On 21/02/2021 13.47, glaub...@debian.org wrote:
>>> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
>> platforms. There is no separate configure guard. All platforms th
On 2/21/21 7:12 PM, Christian Heimes wrote:
> On 21/02/2021 13.47, glaub...@debian.org wrote:
>> 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 i
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 mea
On 21/02/2021 23:06, Terry Reedy wrote:
On 2/21/2021 12:04 PM, Paul Sokolovsky wrote:
Traceback (most recent call last):
File "pseudoc_tool.py", line 91, in
first_class_function_value(func, **pass_params)
TypeError: print() got an unexpected keyword argument 'noann'
This is not typic
On 2/22/2021 6:20 AM, Victor Stinner wrote:
To have an idea of the existing maintenance burden, look at emails sent to:
https://mail.python.org/archives/list/buildbot-sta...@python.org/
Every single email is basically a problem. There are around 110 emails
over the last 30 years:
30 days, not
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
On 2/22/2021 6:58 AM, Victor Stinner wrote:
On Mon, Feb 22, 2021 at 12:51 PM Ivan Pozdeev via Python-Dev
wrote:
IIRC I suggested earlier that buildsbots should be integrated into the PR
workflow in order to make it the contributor's rather than a core
dev's burden to fix any breakages that res
On 2/22/2021 5:18 PM, Matthias Klose wrote:
On 2/21/21 1:13 PM, Victor Stinner wrote:
Document what is supported, be inclusive about anything else. Don't make a
distinction yet between legacy and upcoming new architectures.
I agree with this, and I don't see any reason why we shouldn't just us
In case anyone is wondering what mingw-w64-python is referring to:
https://packages.msys2.org/base/mingw-w64-python
The MSYS2 project [0] maintains a CPython variant that builds with
gcc/clang+mingw-w64 on Windows. We lack the manpower to reduce the diff to
upstream though. The yearly rebuilds,
> On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote:
>
> It looks like:
>
> Traceback (most recent call last):
> File "pseudoc_tool.py", line 91, in
> File ".../xforms.py", line 25, in print
> TypeError: unexpected keyword argument 'noann'
>
> - that makes clear that it's "print" function of
On 2/22/21, 1:39 PM, "Steve Dower" wrote:
On 2/22/2021 5:18 PM, Matthias Klose wrote:
> On 2/21/21 1:13 PM, Victor Stinner wrote:
> Document what is supported, be inclusive about anything else. Don't make
a
> distinction yet between legacy and upcoming new architectures.
I
> On 22 Feb 2021, at 12:40, Michał Górny wrote:
>
>> I'm talking about 16-bit memory alignment which causes SIGBUS if it's
>> not respected on m68k.
>>
>
> I don't understand why you consider this to be a problem. After all,
> x86 has stronger (32-bit) alignment requirements, so m68k is actu
Hello,
On Mon, 22 Feb 2021 19:47:04 +
Barry Scott wrote:
> > On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote:
> >
> > It looks like:
> >
> > Traceback (most recent call last):
> > File "pseudoc_tool.py", line 91, in
> > File ".../xforms.py", line 25, in print
> > TypeError: unexpected
> > Example: 16-bit m68k
> no, it's a 32bit platform with extra alignment requirements.
Actually, fewer. Most architectures have alignof(x) == sizeof(x) for all the
primitive types, but m68k is more relaxed and caps alignof(x) at 2. This means
that assert((p & sizeof(long)) == 0) is too strict,
On Mon, 22 Feb 2021 19:50:43 +
Rob Boehne wrote:
>
> The other thing that crept into this thread was the mention of test that
> intermittently fail.
> That's a huge problem because it suggests that applications will sometimes
> fail.
> I have usually seen these sort of issues because of
>
On Mon, 2021-02-22 at 19:54 +, Barry Scott wrote:
>
> > On 22 Feb 2021, at 12:40, Michał Górny wrote:
> >
> > > I'm talking about 16-bit memory alignment which causes SIGBUS if it's
> > > not respected on m68k.
> > >
> >
> > I don't understand why you consider this to be a problem. After
On Mon, 2021-02-22 at 19:27 +, Jessica Clarke wrote:
> > > Example: 16-bit m68k
> > no, it's a 32bit platform with extra alignment requirements.
>
> Actually, fewer. Most architectures have alignof(x) == sizeof(x) for
> all the primitive types, but m68k is more relaxed and caps alignof(x)
> at
On Sun, Feb 21, 2021 at 12:28 PM Gregory P. Smith wrote:
>
> On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes
> wrote:
>
>> On 21/02/2021 13.47, glaub...@debian.org wrote:
>> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
>> platforms. There is no separate configure guard.
Barry Scott wrote:
> > On 22 Feb 2021, at 12:40, Michał Górny mgo...@gentoo.org wrote:
> > I'm talking about 16-bit memory alignment which
> > causes SIGBUS if it's
> > not respected on m68k.
> > I don't understand why you consider this to be a problem. After all,
> > x86 has stronger (32-bit) ali
Michał Górny wrote:
> On Mon, 2021-02-22 at 19:27 +, Jessica Clarke wrote:
> > Example: 16-bit m68k
> > no, it's a 32bit platform with extra alignment requirements.
> > Actually, fewer. Most architectures have alignof(x) == sizeof(x) for
> > all the primitive types, but m68k is more relaxed and
This, and an earlier letter about the burned of a release manager, confirmes my suspicion that a large share of "maintenance burden" comes
from unresolved process issues.
E.g. looks like Victor had been unconvinced that unreliable tests are a serious issue and cost the team so much (including hi
Hi all,
We would like to request feedback on PEP 654 -- Exception Groups and
except*.
https://www.python.org/dev/peps/pep-0654/
It proposes language extensions that allow programs to raise and handle
multiple unrelated
exceptions simultaneously, motivated by the needs of asyncio and other
concur
The default Make flags differ from platform to platform (and compiler
to compiler, IIRC) as well. Thanks for this overview of RHEL/Fedora
Python build security flags.
( Containers are the easiest way to get per- python interpreter
SELinux contexts ( in order to limit the impact of exploitation of
33 matches
Mail list logo
