[Python-Dev] Re: Defining tiered platform support

[Petr Viktorin]

On 08. 03. 22 0:30, Brett Cannon wrote:



On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes > wrote:


On 07/03/2022 18.02, Petr Viktorin wrote:
 >> Why the devguide? I view the list of platforms as important for
public
 >> consumption as for the core dev team to know what to (not)
accept PRs
 >> for.
 >
 > So, let's put it in the main docs?
 > Yes, I guess the devguide is a weird place to check for this kind of
 > info. But a Python enhancement proposal is even weirder.


+1 for our main docs (cpython/Doc/)

Platform support is Python versions specific. Python 3.10 may support
different version than 3.11 or 3.12. It makes sense to keep the support
information with the code.


Technically it's CPython version-specific. I also don't know where we 
would list this in the docs. Looking at https://docs.python.org/3/ 
 I wouldn't know where to look for such 
information.


Yeah, I kind of have the same issue with backcompat expectations 
(https://discuss.python.org/t/documenting-python-versioning-and-stability-expectations/11090). 
We might need a new section for this kind of CPython-specific docs.
Maybe repurpose the "Python Setup and Usage" section, which is 
CPython-specific already.

___
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/SBC4SNWPCFRMC4KYIPC2VUJU7REJQ6DU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes 
wrote:

> On 07/03/2022 18.02, Petr Viktorin wrote:
> >> Why the devguide? I view the list of platforms as important for public
> >> consumption as for the core dev team to know what to (not) accept PRs
> >> for.
> >
> > So, let's put it in the main docs?
> > Yes, I guess the devguide is a weird place to check for this kind of
> > info. But a Python enhancement proposal is even weirder.
>
>
> +1 for our main docs (cpython/Doc/)
>
> Platform support is Python versions specific. Python 3.10 may support
> different version than 3.11 or 3.12. It makes sense to keep the support
> information with the code.
>

Technically it's CPython version-specific. I also don't know where we would
list this in the docs. Looking at https://docs.python.org/3/ I wouldn't
know where to look for such information.
___
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/OYVN2XROV6DQ5IYBM5NT7EHSAJLDXFE5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 7, 2022 at 11:01 AM Christian Heimes 
wrote:

> On 04/03/2022 21.41, Brett Cannon wrote:
> > Therefore I propose that we target the oldest manylinux standard
> > accepted by PyPI, for which the operating system has not reached its
> > EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL
> June
> > 2024. We could also state that we aim for compatibility with oldest
> > Debian Stable and Ubuntu LTS with standard, free security updates.
> > As of
> > today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions
> with
> > regular updates.
> >
> >
> > So does that mean you want to list the Linux distros explicitly? Or you
> > want to explicitly list the glibc version?
>
> I want to explicitly mention glibc and Linux distro for manylinux binary
> wheels standards that are supported by PyPI. For the rest we should be a
> bit more hand-wavy. Maybe we can point to our list of stable buildbots?
>

How about we list Linux support as based on the libc implementation and
version and point as various stable buildbots that cover that libc?


>
> >
> > We should say something about compilers. I wouldn't list compiler
> > versions, though. Compiler features like C99 support should be
> > sufficient.
> >
> >
> > Then what more would you want than what's listed in PEP 7 already?
>
> Nothing in particular other than a link to the PEP, so people can
> discover the requirement more easily.
>


___
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/OEN667JU2ATPU75XPOBZAAU4BS72IXCH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Christian Heimes]

On 07/03/2022 18.02, Petr Viktorin wrote:
Why the devguide? I view the list of platforms as important for public 
consumption as for the core dev team to know what to (not) accept PRs 
for.


So, let's put it in the main docs?
Yes, I guess the devguide is a weird place to check for this kind of 
info. But a Python enhancement proposal is even weirder.



+1 for our main docs (cpython/Doc/)

Platform support is Python versions specific. Python 3.10 may support 
different version than 3.11 or 3.12. It makes sense to keep the support 
information with the code.


Christian
___
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/LJID7Y7RFSCRUYLJS3E56WBGJU2R44E4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Christian Heimes]

On 04/03/2022 21.41, Brett Cannon wrote:

Therefore I propose that we target the oldest manylinux standard
accepted by PyPI, for which the operating system has not reached its
EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June
2024. We could also state that we aim for compatibility with oldest
Debian Stable and Ubuntu LTS with standard, free security updates.
As of
today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with
regular updates.


So does that mean you want to list the Linux distros explicitly? Or you 
want to explicitly list the glibc version?


I want to explicitly mention glibc and Linux distro for manylinux binary 
wheels standards that are supported by PyPI. For the rest we should be a 
bit more hand-wavy. Maybe we can point to our list of stable buildbots?




We should say something about compilers. I wouldn't list compiler
versions, though. Compiler features like C99 support should be
sufficient.


Then what more would you want than what's listed in PEP 7 already?


Nothing in particular other than a link to the PEP, so people can 
discover the requirement more easily.


Christian
___
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/TM3NTO652FLS4XUX7QTMTP7GSX6DQRRH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.11.0a6 is available

[Pablo Galindo Salgado]

There are no easy releases these days! :sweat: After a week of delay due to
several release blockers, buildbot problems and pandemic-related
difficulties here is 3.11.0a6 for you to test.

https://www.python.org/downloads/release/python-3110a6/

**This is an early developer preview of Python 3.11**

# Major new features of the 3.11 series, compared to 3.10

Python 3.11 is still in development.  This release, 3.11.0a6 is the sixth
of seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of the
beta phase (2022-05-06) and, if necessary, may be modified or deleted up
until the release candidate phase (2022-08-01).  Please keep in mind that
this is a preview release and its use is **not** recommended for production
environments.

Many new features for Python 3.11 are still being planned and written.
Among the new major new features and changes so far:

* [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include
Fine-Grained Error Locations in Tracebacks
* [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups
and except*
* [PEP 673](https://www.python.org/dev/peps/pep-0673/)  -- Self Type
* [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics
* The [Faster Cpython Project](https://github.com/faster-cpython) is
already yielding some exciting results: this version of CPython 3.11 is
~12% faster on the geometric mean of the [PyPerformance benchmarks](
speed.python.org), compared to 3.10.0.
 * Hey, **fellow core developer,** if a feature you find important is
missing from this list, let me know.

The next pre-release of Python 3.11 will be 3.11.0a7, currently scheduled
for Tuesday, 2022-04-05.

# More resources

* [Online Documentation](https://docs.python.org/3.11/)
* [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release
Schedule
* Report bugs at [https://bugs.python.org](https://bugs.python.org).
* [Help fund Python and its community](/psf/donations/).

# And now for something completely different

In astrophysics and nuclear physics, nuclear pasta is a theoretical type of
degenerate matter that is postulated to exist within the crusts of neutron
stars. If it does in fact exist, nuclear pasta is the strongest material in
the universe. Between the surface of a neutron star and the quark-gluon
plasma at the core, at matter densities of 1014 g/cm3, nuclear attraction
and Coulomb repulsion forces are of similar magnitude. The competition
between the forces leads to the formation of a variety of complex
structures assembled from neutrons and protons. Astrophysicists call these
types of structures nuclear pasta because the geometry of the structures
resembles various types of pasta.

There are several phases of evolution (I swear these names are real),
including the gnocchi phase, the spaghetti phase, the lasagna phase, the
bucatini phase and the Swiss cheese phase.

# We hope you enjoy those new releases!

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
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/LM22QZ4WYXJ6HDSBP33X22BTJF7GJYIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on PEP 655: Required[] and NotRequired[] for TypedDict

[Guido van Rossum]

Maybe this shouldn't be called syntax but notation or convention?

On Mon, Mar 7, 2022 at 7:00 AM Petr Viktorin  wrote:

> Hello,
> I'm sorry for my late reply -- keeping up with all the PEPs is
> somewhat challenging.
>
> The one nitpick I have is that the PEP should make a few things more
> clear to people outside the typing-sig:
> - if this PEP really only affects typing.py and external
> projects/tools, it should say so clearly (so e.g. a parser experts can
> skip reading the PEP with clear conscience, even though it "introduces
> two new syntaxes")
> - in Specification, clarify what "It is an error" means -- is it a
> Python runtime error, or an error type checkers should raise? Same for
> "It is valid".
>
> To be clear, I don't think this should block the PEP.
>
>
> On Wed, Feb 16, 2022 at 4:58 PM David Foster  wrote:
> >
> > Hi folks, PEP 655 (Required[] and NotRequired[] for TypedDict) is still
> > looking for feedback from core devs.
> >
> > I've copied the latest PEP text at the bottom of this email to make it
> > easier to comment on.
> >
> > Thank you for your time.
> >
> > Best,
> > --
> > David Foster | Seattle, WA, USA
> > Contributor to Python's type system
> ___
> 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/YT23XQSNUJF3S4HO5MWGOH3GR5GP4Y7Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/RV3DX5M6CACGIAYSBG65I7UZMKL4FVTI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Petr Viktorin]

On 04. 03. 22 21:48, Brett Cannon wrote:



On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin > wrote:


On 04. 03. 22 0:30, Brett Cannon wrote:
 > Do we officially support NetBSD? Do you know how to find out if
we do?
 > You might think to look at
 > https://www.python.org/dev/peps/pep-0011/#supporting-platforms

 > > , but
 > that just loosely defines the criteria and it still doesn't list the
 > actual platforms we support. (BTW I don't know if we do officially
 > support NetBSD, hence this email.)
 >
 > I think we should clarify this sort of thing and be a bit more
upfront
 > with the level of support we expect/provide for a platform. As
such, I
 > want to restructure PEP 11 to list the platforms we support, not
just
 > list the platforms we stopped supporting. To do this I want define 3
 > different tiers that outline what our support requirements and
promises
 > are for platforms.

While you're at it: consider moving the lists to the devguide, so the
PEP would only contain the general process & criteria.


Why the devguide? I view the list of platforms as important for public 
consumption as for the core dev team to know what to (not) accept PRs for.


So, let's put it in the main docs?
Yes, I guess the devguide is a weird place to check for this kind of 
info. But a Python enhancement proposal is even weirder.




 > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
 > Linux w/ the latest glibc (I don't know of a better way to define
Linux
 > support as I don't know if a per-distro list is the right
abstraction).
 > These are platforms we won't even let code be committed for if they
 > would break; they block releases if they don't work. These
platforms we
 > all implicitly promise to support.
 >
 > Tier 2 is the platforms we would revert a change within 24 hours
if they
 > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
 > glibc.This is historically the "stable buildbot plus a core dev"
group
 > of platforms. The change I would like to see is two core devs (in
case
 > one is on vacation), and a policy as to how a platform ends up here
 > (e.g. SC must okay it based on consensus of everyone). The stable
 > buildbot would still be needed to know if a release is blocked as we
 > would hold a release up if they were red. The platform and the
core devs
 > supporting these platforms would be listed in PEP 11.

Do we need two core devs to revert changes?


No, but consider you are trying to land something before b1 and a tier 2 
platform keeps failing. You have no idea why, but e.g. Victor is on 
vacation and is unavailable to help. I personally wouldn't want to wait 
until the next version of Python just because a platform we say we 
support had its expert take an inconvenient vacation.


Sure, requiring two core devs will help with that. But two seems about 
as arbitrary as one. People can have overlapping vacations, and some 
core devs are less responsive than Victor on vacation :)

Is this an existing, recurring issue we need to solve?
___
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/XTRF3IH4LN3Z6RC6KGS5IJCWMTL3GAYL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on PEP 655: Required[] and NotRequired[] for TypedDict

[Petr Viktorin]

Hello,
I'm sorry for my late reply -- keeping up with all the PEPs is
somewhat challenging.

The one nitpick I have is that the PEP should make a few things more
clear to people outside the typing-sig:
- if this PEP really only affects typing.py and external
projects/tools, it should say so clearly (so e.g. a parser experts can
skip reading the PEP with clear conscience, even though it "introduces
two new syntaxes")
- in Specification, clarify what "It is an error" means -- is it a
Python runtime error, or an error type checkers should raise? Same for
"It is valid".

To be clear, I don't think this should block the PEP.


On Wed, Feb 16, 2022 at 4:58 PM David Foster  wrote:
>
> Hi folks, PEP 655 (Required[] and NotRequired[] for TypedDict) is still
> looking for feedback from core devs.
>
> I've copied the latest PEP text at the bottom of this email to make it
> easier to comment on.
>
> Thank you for your time.
>
> Best,
> --
> David Foster | Seattle, WA, USA
> Contributor to Python's type system
___
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/YT23XQSNUJF3S4HO5MWGOH3GR5GP4Y7Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improvements to the sys.path initialization documentation

[Nick Coghlan]

On Mon, 7 Mar 2022, 7:42 pm Victor Stinner,  wrote:

> On Fri, Mar 4, 2022 at 1:37 PM Eryk Sun  wrote:
> > I don't understand. The site packages directories, including virtual
> > environments, are a site extension.
>
> I propose to change that. Move all code related to sys.path from the
> site module to the Modules/getpath.py module.
>

Certain entries not being on sys.path when the site module isn't loaded is
a feature (the "-S" CLI option), not a bug to be fixed.

Those site entries haven't historically been the really confusing part of
path inititialisation - it's been finding out where all the *other* default
entries are coming from, so you can get a clearer picture of what's always
there vs what's being added by the site module.

Cheers,
Nick.



> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/HXD2JIDHBX7BFIU3FA7R3LWRFEXQMVYW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/ICOGZEUBU7BAL25OUMMTFSJ2VSVVYN43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improvements to the sys.path initialization documentation

[Victor Stinner]

On Fri, Mar 4, 2022 at 1:37 PM Eryk Sun  wrote:
> I don't understand. The site packages directories, including virtual
> environments, are a site extension.

I propose to change that. Move all code related to sys.path from the
site module to the Modules/getpath.py module.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/HXD2JIDHBX7BFIU3FA7R3LWRFEXQMVYW/
Code of Conduct: http://python.org/psf/codeofconduct/