from:"Pablo Galindo Salgado"

[python-committers] [RELEASE] Python 3.11.2, Python 3.10.10 and 3.12.0 alpha 5 are available

2023-02-08 Thread Pablo Galindo Salgado

Hi everyone,

I am happy to report that after solving some last-time problems we have a
bunch of fresh releases for you:

### Python 3.12.0 alpha 5

Check the new alpha of 3.12 with some Star Trek vibes:

https://www.python.org/downloads/release/python-3120a5/

210 new commits since 3.12.0a4 last month

### Python 3.11.2

A shipment of bugfixes and security releases for the newest Python!

https://www.python.org/downloads/release/python-3112/

194 new commits since 3.11.1

### Python 3.10.10

Your trusty Python3.10 just got more stable and secure!

https://www.python.org/downloads/release/python-31010/

131 new commits since 3.10.9

## We hope you enjoy the 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.

https://www.python.org/psf/

Your friendly release team,

Ned Deily @nad
Steve Dower @steve.dower
Pablo Galindo Salgado @pablogsal
Łukasz Langa @ambv
Thomas Wouters @thomas
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/P4JHHHAAO4L4KFZQ6PX5J3JRPAZUXJWJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Thank you for your contributions to Python 3.11!

2022-10-26 Thread Pablo Galindo Salgado

Hi everyone,

Now that the 3.11.0 release is finally done and I can relax a bit, I just
wanted to thank you all
for your fantastic work that has made Python 3.11 such a fantastic release.
No matter if you committed
code to 3.11 or opened a bug, helped with the documentation, reviewed pull
requests, participated in
discussions, made a PEP or help writing one, fixed a bug or one hundred or
make optimizations to the
interpreter or any other of the many ways to contribute. Your work makes a
huge difference and Python
3.11 is much better because of that :)

Also, I want to especially thank all core devs and contributors that have
helped me and the release team take
care of release blockers, buildbot failures, CVE patches, and any other
form of release crisis. Thank you!

Finally, a huge thanks to my colleagues in the release team that make these
releases possible and help to make
sure that my mistakes are not too obvious to end users :P

Being your release manager for 3.11 and 3.10 has been a privilege and an
honor (and it will continue for a couple
of years of bugfixes and security releases, I'm not going anywhere).

Regards from rainy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TKNPRJI7QXHC73EKKTN2N5PMEX26POIP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11 final (3.11.0) is available

2022-10-24 Thread Pablo Galindo Salgado

Python 3.11 is finally released. In the CPython release team, we have put a
lot of effort into making 3.11 the best version of Python possible. Better
tracebacks, faster Python, exception groups and except*, typing
improvements and much more. Get it here:

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

## This is the stable release of Python 3.11.0

Python 3.11.0 is the newest major release of the Python programming
language, and it contains many new features and optimizations.

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

Some of the new major new features and changes in Python 3.11 are:

## General changes

* [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 680](https://www.python.org/dev/peps/pep-0680/) -- tomllib: Support
for Parsing TOML in the Standard Library
* [gh-90908](https://github.com/python/cpython/issues/90908) -- Introduce
task groups to asyncio
* [gh-34627](https://github.com/python/cpython/issues/34627/) -- Atomic
grouping (`(?>...)`) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are
now supported in regular expressions.
* The [Faster CPython Project](https://github.com/faster-cpython/) is
already yielding some exciting results. Python 3.11 is up to 10-60% faster
than Python 3.10. On average, we measured a 1.22x speedup on the standard
benchmark suite. See [Faster CPython](
https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details.

## Typing and typing language changes

* [PEP 673](https://www.python.org/dev/peps/pep-0673/) --  Self Type
* [PEP 646](https://www.python.org/dev/peps/pep-0646/) -- Variadic Generics
* [PEP 675](https://www.python.org/dev/peps/pep-0675/) -- Arbitrary Literal
String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/) -- Marking
individual TypedDict items as required or potentially-missing
* [PEP 681](https://www.python.org/dev/peps/pep-0681/) -- Data Class
Transforms

# 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://github.com/python/cpython/issues](https://github.com/python/cpython/issues)
.
* [Help fund Python and its community](/psf/donations/).

# And now for something completely different

When a spherical non-rotating body of a critical radius collapses under its
own gravitation under general relativity, theory suggests it will collapse
to a single point. This is not the case with a rotating black hole (a Kerr
black hole). With a fluid rotating body, its distribution of mass is not
spherical (it shows an equatorial bulge), and it has angular momentum.
Since a point cannot support rotation or angular momentum in classical
physics (general relativity being a classical theory), the minimal shape of
the singularity that can support these properties is instead a ring with
zero thickness but non-zero radius, and this is referred to as a
ringularity or Kerr singularity.

This kind of singularity has the following peculiar property. The spacetime
allows a geodesic curve (describing the movement of observers and photons
in spacetime) to pass through the center of this ring singularity. The
region beyond permits closed time-like curves. Since the trajectory of
observers and particles in general relativity are described by time-like
curves, it is possible for observers in this region to return to their
past. This interior solution is not likely to be physical and is considered
a purely mathematical artefact.

There are some other interesting free-fall trajectories. For example, there
is a point in the axis of symmetry that has the property that if an
observer is below this point, the pull from the singularity will force the
observer to pass through the middle of the ring singularity to the region
with closed time-like curves and it will experience repulsive gravity that
will push it back to the original region, but then it will experience the
pull from the singularity again and will repeat this process forever. This
is, of course, only if the extreme gravity doesn’t destroy the observer
first.

# We hope you enjoy the 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.

https://www.python.org/psf/

If you have any questions, please reach out to me or another member of the
release team :)

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email

[python-committers] Re: IMPORTANT: Check the 3.11.0 cherry-picks

2022-10-24 Thread Pablo Galindo Salgado

Hummm, list_resize() is here:

https://github.com/python/cpython/commit/38ade0d2aca25748207189b17323874cad183f78
 
<https://github.com/python/cpython/commit/38ade0d2aca25748207189b17323874cad183f78>

I am force-pushing to that branch when I need to rebase or cherry-pick with 
merge conflicts so the SHAs may change (maybe that’s why GitHub shows that 
message).

> On 24 Oct 2022, at 16:59, Gregory P. Smith  wrote:
> 
> 
> 
> On Mon, Oct 24, 2022 at 3:59 AM Pablo Galindo Salgado  <mailto:pablog...@gmail.com>> wrote:
> Hi everyone,
> 
> I emerged from cherry-picking hell! As mentioned previously, the 3.11.0 final 
> release will be done from the "branch-v3.11.0" branch
> and will contain a bunch of cherry-picked commits on top of v3.11.0rc2. These 
> commits are:
> 
> * All documentation commits that **do not touch** any source code (120+ 
> commits).
> * The following bugfixes:
> + 6b82cb8 gh-95027: Fix regrtest stdout encoding on Windows (GH-98492)
> + 970c10aa6d0 gh-97616: list_resize() checks for integer overflow (GH-97617)
> + 67f5d24e44c gh-96848: Fix -X int_max_str_digits option parsing (GH-96988)
> + 9e008fe3519 gh-96821: Fix undefined behaviour in `_testcapimodule.c` 
> (GH-96915) (GH-96927)
> + bac61bc5b13 gh-95778: Mention sys.set_int_max_str_digits() in error message 
> (GH-96874)
> + 9cb7324e8fc [3.11] gh-96587: Raise `SyntaxError` for PEP654 on older 
> `feature_version` (GH-96588) (#96591)
> + 84fd4a54a61 [3.11] gh-97897: Prevent os.mkfifo and os.mknod segfaults with 
> macOS 13 SDK (GH-97944) (#97969)
> + 1a788914ca6 gh-96865: [Enum] fix Flag to use CONFORM boundary (GH-97528)
> + c95433573ac [3.11] gh-98331: Update bundled pip to 22.3 (GH-98332) 
> (gh-98400)
> + fc127628d58 gh-98414: py.exe launcher does not use defaults for -V:company/ 
> option (GH-98460)
> + 585c95df957 [3.11] GH-97752: Clear the previous member of newly-created 
> generator/coroutine frames (GH-97812)
> + 4e0fda59f1f gh-98360: multiprocessing now spawns children on Windows with 
> correct argv[0] in virtual environments (GH-98462)
> + 4c0c1e201a8 [3.11] gh-97514: Don't use Linux abstract sockets for 
> multiprocessing (GH-98501) (GH-98502)
> + d0ab10f6f01 [3.11] GH-97002: Prevent _PyInterpreterFrames from backing more 
> than one PyFrameObject (GH-98002)
> + 154b3cd7516 GH-96975: Skip incomplete frames in PyEval_GetFrame (GH-97018)
> 
> Please check these commits and let me know ASAP if we are missing something 
> you would like to include on the 3.11.0 final release.
> 
> You have until 15:00 UTC+0 today to let me know, otherwise, your changes will 
> need to wait until 3.11.1.
> 
> Github is claiming this list_resize() commit does not exist on a branch for 
> me?
>  https://github.com/python/cpython/commit/970c10aa6d0 
> <https://github.com/python/cpython/commit/970c10aa6d0>
> 
> Is that just github being wonky or something else?
> 
> I double checked the following commits and they look good and show up on 
> github as being on branch-v3.11.0:
>  https://github.com/python/cpython/commit/67f5d24e44c 
> <https://github.com/python/cpython/commit/67f5d24e44c>
>  https://github.com/python/cpython/commit/bac61bc5b13 
> <https://github.com/python/cpython/commit/bac61bc5b13>
>  https://github.com/python/cpython/commit/4c0c1e201a8 
> <https://github.com/python/cpython/commit/4c0c1e201a8>
> 
> I didn't check others, those were the ones I was familiar with.
>  
> -gps
> 
> 
> Thanks for your help!
> 
> Regards from sunny London,
> Pablo Galindo Salgado
> ___
> python-committers mailing list -- python-committers@python.org 
> <mailto:python-committers@python.org>
> To unsubscribe send an email to python-committers-le...@python.org 
> <mailto:python-committers-le...@python.org>
> https://mail.python.org/mailman3/lists/python-committers.python.org/ 
> <https://mail.python.org/mailman3/lists/python-committers.python.org/>
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/SB5PWB32JQHE7QFIULXIZIGUFPKSYEKP/
>  
> <https://mail.python.org/archives/list/python-committers@python.org/message/SB5PWB32JQHE7QFIULXIZIGUFPKSYEKP/>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ 
> <https://www.python.org/psf/codeofconduct/>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CGBGLK6DPJBOO4KMMDMSWJYM4RRQKVXN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] IMPORTANT: Check the 3.11.0 cherry-picks

2022-10-24 Thread Pablo Galindo Salgado

Hi everyone,

I emerged from cherry-picking hell! As mentioned previously, the 3.11.0
final release will be done from the "branch-v3.11.0" branch
and will contain a bunch of cherry-picked commits on top of v3.11.0rc2.
These commits are:

* All documentation commits that **do not touch** any source code (120+
commits).
* The following bugfixes:

+ 6b82cb8 gh-95027: Fix regrtest stdout encoding on Windows (GH-98492)
+ 970c10aa6d0 gh-97616: list_resize() checks for integer overflow (GH-97617)
+ 67f5d24e44c gh-96848: Fix -X int_max_str_digits option parsing (GH-96988)
+ 9e008fe3519 gh-96821: Fix undefined behaviour in `_testcapimodule.c`
(GH-96915) (GH-96927)
+ bac61bc5b13 gh-95778: Mention sys.set_int_max_str_digits() in error
message (GH-96874)
+ 9cb7324e8fc [3.11] gh-96587: Raise `SyntaxError` for PEP654 on older
`feature_version` (GH-96588) (#96591)
+ 84fd4a54a61 [3.11] gh-97897: Prevent os.mkfifo and os.mknod segfaults
with macOS 13 SDK (GH-97944) (#97969)
+ 1a788914ca6 gh-96865: [Enum] fix Flag to use CONFORM boundary (GH-97528)
+ c95433573ac [3.11] gh-98331: Update bundled pip to 22.3 (GH-98332)
(gh-98400)
+ fc127628d58 gh-98414: py.exe launcher does not use defaults for
-V:company/ option (GH-98460)
+ 585c95df957 [3.11] GH-97752: Clear the previous member of newly-created
generator/coroutine frames (GH-97812)
+ 4e0fda59f1f gh-98360: multiprocessing now spawns children on Windows with
correct argv[0] in virtual environments (GH-98462)
+ 4c0c1e201a8 [3.11] gh-97514: Don't use Linux abstract sockets for
multiprocessing (GH-98501) (GH-98502)
+ d0ab10f6f01 [3.11] GH-97002: Prevent _PyInterpreterFrames from backing
more than one PyFrameObject (GH-98002)
+ 154b3cd7516 GH-96975: Skip incomplete frames in PyEval_GetFrame (GH-97018)


Please *check these commits* and let me know ASAP if we are missing
something you would like to include on the 3.11.0 final release.

You have until 15:00 UTC+0 today to let me know, otherwise, your changes
will need to wait until 3.11.1.

Thanks for your help!

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SB5PWB32JQHE7QFIULXIZIGUFPKSYEKP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] RELEASE MANAGEMENT: Python 3.11 release stream

2022-10-22 Thread Pablo Galindo Salgado

Hi everyone,

I am currently swamped fixing merge conflicts from the cherry-picking to
the final release candidate but I wanted to write to tell you I'm excited
to confirm that we will be haven a Python 3.11 release party as we did last
year with 3.10. The event will be co-hosted by the fantastic people of the
Python discord channel. The URL for the stream is this one:

https://www.youtube.com/watch?v=PGZPSWZSkJI

*The release party will start on October 24th at 17:00 UTC+0.*
In this stream, some core developers (Irit, Mark, Brandt, Thomas and
Łukasz) will be talking about Python 3.11 features, the work on the faster
CPython project, some sneak peek on Python 3.12 and beyond, talking about
the core Dev in residence role and other things with some time for
moderated Q&A. I will be doing the release live and will also cover what I
am doing. Is a fantastic opportunity to watch me break everything live :)

Who knows, maybe I break GitHub. again! :D

In the end, people from the audience will be able to ask questions in a
moderated Q&A, so it would be fantastic if you can be there to maybe answer
some questions from the comments or complete the ones we give (or correct
us if we say something wrong). Or you can just hang out quietly. Whatever
you prefer is good!

The main purpose of the stream is to raise excitement about Python 3.11,
explain the new features to users, try to get the community closer to the
core Dev team and allow them to ask questions to the core dev team. Also,
funny party hats will be used!

I hope you find the event interesting and consider attending. Python 3.11
is going to be a fantastic release and we want it to be even better :)

Please, reach out to me if you have any questions or suggestions.

Regards from rainy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/IXKQMO36OYE5MUN3XIGNJEOQ2VGLZKUJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11 release candidate 2 (3.11.0rc2) is available

2022-09-12 Thread Pablo Galindo Salgado

ole region in its past. This region does not exist for black
holes that have formed through gravitational collapse, however, nor are
there any observed physical processes through which a white hole could be
formed. Supermassive black holes are theoretically predicted to be at the
centre of every galaxy and that possibly, a galaxy cannot form without one.
Stephen Hawking and others have proposed that these supermassive black
holes spawn a supermassive white hole.

# We hope you enjoy the 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.

https://www.python.org/psf/

If you have any questions, please reach out to me or another member of the
release team :)

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/EURTP5F4XUQXWVSUQ4R3UJQ5GANHHMKO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11.0 RC2 is blocked

2022-09-05 Thread Pablo Galindo Salgado

Hi everyone,

Today was the scheduled release of Python 3.11.0 RC2 but unfortunately, we
have a bunch of release
blockers. Here are some of them:

https://github.com/python/cpython/issues/96569
https://github.com/python/cpython/issues/96559
https://github.com/python/cpython/issues/96572
https://github.com/python/cpython/issues/96046
https://github.com/python/cpython/issues/95027

Here is the current GH query:

https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Arelease-blocker+label%3A3.11

Some of these issues were opened today or yesterday and some others are
likely already solved but need
someone to confirm that there is nothing left for 3.11. Until these
issues are resolved I won't be able to continue
with the release of 3.11.0 RC2.

Please, also remember that after 3.11.0 RC2 there should not be **any code
changes** (ideally, obviously if something
major is discovered we will include it in 3.11.0). So if you have any
bugfix or similar that you want to get included in 3.11.0
please let me know ASAP otherwise, it will need to wait for 3.11.1.

Thank you very much for your help!

Regards from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TKFELC4AXKSYMJXCZNZYE7O5OR7ZGTXH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11 release candidate 1 (3.11.0rc1) is available

2022-08-08 Thread Pablo Galindo Salgado

ese reasons among the unsolved problems
in physics.

# We hope you enjoy the 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.

https://www.python.org/psf/

If you have any questions, please reach out to me or another member of the
release team :)

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JV3LYX3SBGMLMIK7HLNZTLFPY4RMP3NZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.6 is available

2022-08-02 Thread Pablo Galindo Salgado

Here you have a nice package of 200 commits of bugfixes and documentation
improvements freshly made for Python 3.10. Go and download it when is still
hot:

https://www.python.org/downloads/release/python-3106/

## This is the sixth maintenance release of Python 3.10

Python 3.10.6 is the newest major release of the Python programming
language, and it contains many new features and optimizations.

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

Among the new major new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and
prepare for the removal of the wstr member in PyUnicodeObject.
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial
* [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL
1.1.1 or newer
* [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove
Py_UNICODE encoder APIs
* [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional
EncodingWarning

[bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to
be on this list
in previous pre-releases but it has been postponed to Python 3.11 due to
some compatibility concerns. You can read the Steering Council
communication about it [here](
https://mail.python.org/archives/list/python-...@python.org/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/)
to learn more.

# More resources

* [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog
)
* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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
A pentaquark is a human-made subatomic particle, consisting of four quarks
and one antiquark bound together; they are not known to occur naturally or
exist outside of experiments to create them. As quarks have a baryon number
of (+1/3), and antiquarks of (−1/3), the pentaquark would have a total
baryon number of 1 and thus would be a baryon. Further, because it has five
quarks instead of the usual three found in regular baryons (a.k.a.
'triquarks'), it is classified as an exotic baryon. The name pentaquark was
coined by Claude Gignoux et al. (1987) and Harry J. Lipkin in 1987;
however, the possibility of five-quark particles was identified as early as
1964 when Murray Gell-Mann first postulated the existence of quarks.
Although predicted for decades, pentaquarks proved surprisingly tricky to
discover and some physicists were beginning to suspect that an unknown law
of nature prevented their production.


# We hope you enjoy the 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.

https://www.python.org/psf/

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/H264J7IX6MYWM532ER4YH3DMW3CCHTRP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] The last 3.11 beta release (3.11.0b5) is now available

2022-07-26 Thread Pablo Galindo Salgado

aximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
the spacetime).

The Einstein–Rosen bridge was discovered by Ludwig Flamm in 1916, a few
months after Schwarzschild published his solution, and was rediscovered by
Albert Einstein and his colleague Nathan Rosen, who published their result
in 1935. However, in 1962, John Archibald Wheeler and Robert W. Fuller
published a paper showing that this type of wormhole is unstable if it
connects two parts of the same universe and that it will pinch off too
quickly for light (or any particle moving slower than light) that falls in
from one exterior region to make it to the other exterior region.

Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).

# Release hashes

The BSD-style checksum hashes for the release artefacts are:

SHA256 (python-3.11.0b5-amd64.exe) =
0cf9d582da862f2fe207fd54b81dfca110e8f04f4b05ab8c3228ce1ea060c7af
SHA256 (python-3.11.0b5-arm64.exe) =
a71efd9d3835d493d8207a30916ce3417af17295c02a9b0783dc740754f6e40b
SHA256 (python-3.11.0b5-embed-amd64.zip) =
5584ddbd21f45ce74ce0512eeb1d817d15374b1b7a461d79f973f6dd48ab5d9e
SHA256 (python-3.11.0b5-embed-arm64.zip) =
819924f10eb08ea6322b6040a2fb953137866bb1034cd4e8fe6e93c7c0b37e31
SHA256 (python-3.11.0b5-embed-win32.zip) =
18927604bcbe3c226be7864cde0c1f25ad35c6333d9d3125dfff8ca4fc872255
SHA256 (python-3.11.0b5.exe) =
382eb4c6dc1606bd3cf6f4bdeec8e1e7dab444c5aa23b86142d608a480d7c195
SHA256 (python-3.11.0b5-macos11.pkg) =
cd8e6d98e79a4adcd376c486405a535b004cf9a58a71487a11bc424acd815012
SHA256 (Python-3.11.0b5.tar.xz) =
3810bd22f7dc34a99c2a2eb4b85264a4df4f05ef59c4e0ccc2ea82ee9c491698
SHA256 (Python-3.11.0b5.tgz) =
3f7d1a4ab0e64425f4ffd92d49de192ad2ee1c62bc52e3877e9f7b254c702e60

The hashes are also attached to this email.

# We hope you enjoy the 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.

https://www.python.org/psf/

If you have any questions, please reach out to me or another member of the
release team :)

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
SHA256 (python-3.11.0b5-amd64.exe) = 
0cf9d582da862f2fe207fd54b81dfca110e8f04f4b05ab8c3228ce1ea060c7af
SHA256 (python-3.11.0b5-arm64.exe) = 
a71efd9d3835d493d8207a30916ce3417af17295c02a9b0783dc740754f6e40b
SHA256 (python-3.11.0b5-embed-amd64.zip) = 
5584ddbd21f45ce74ce0512eeb1d817d15374b1b7a461d79f973f6dd48ab5d9e
SHA256 (python-3.11.0b5-embed-arm64.zip) = 
819924f10eb08ea6322b6040a2fb953137866bb1034cd4e8fe6e93c7c0b37e31
SHA256 (python-3.11.0b5-embed-win32.zip) = 
18927604bcbe3c226be7864cde0c1f25ad35c6333d9d3125dfff8ca4fc872255
SHA256 (python-3.11.0b5.exe) = 
382eb4c6dc1606bd3cf6f4bdeec8e1e7dab444c5aa23b86142d608a480d7c195
SHA256 (python-3.11.0b5-macos11.pkg) = 
cd8e6d98e79a4adcd376c486405a535b004cf9a58a71487a11bc424acd815012
SHA256 (Python-3.11.0b5.tar.xz) = 
3810bd22f7dc34a99c2a2eb4b85264a4df4f05ef59c4e0ccc2ea82ee9c491698
SHA256 (Python-3.11.0b5.tgz) = 
3f7d1a4ab0e64425f4ffd92d49de192ad2ee1c62bc52e3877e9f7b254c702e60
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/VCLXLDD7PQH6CVG5LBGP6EDFBHQX3F4T/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

2022-07-11 Thread Pablo Galindo Salgado

BSD-style checksum format hashes for the release artefacts:

SHA256 (python-3.11.0b4-embed-arm64.zip) =
272c6bb4948c597f6578f64c2b15a70466c5dfb49f9b84dba57a84e59e7bd4ef
SHA256 (python-3.11.0b4-amd64.exe) =
a3514b0401e6a85416f3e080586c86ccd9e2e62c8a54b9119d9e6415e3cadb62
SHA256 (python-3.11.0b4-macos11.pkg) =
860647775d4e6cd1a8d71412233df5dbe3aa2886fc16d82a59ab2f625464f2d7
SHA256 (python-3.11.0b4-embed-win32.zip) =
36b81da7986f8d59be61adb452681dbd3257ebb90bd89092b2fbbd9356e06425
SHA256 (python-3.11.0b4-arm64.exe) =
ad0d1429682ba1edc0c0cf87f68a3d1319b887b715da70a91db41d02be4997a4
SHA256 (python-3.11.0b4-embed-amd64.zip) =
66e6bb44c36da36ecc1de64efdb92f52ba3a19221dba2a89e22e39f715bd205b
SHA256 (Python-3.11.0b4.tar.xz) =
1d93b611607903e080417c1a9567f5fbbf5124cc5c86f4afbba1c8fd34c5f6fb
SHA256 (python-3.11.0b4.exe) =
6febc152711840337f53e2fd5dc12bb2b1314766f591129282fd372c855fa877
SHA256 (Python-3.11.0b4.tgz) =
257e753db2294794fa8dec072c228f3f53fd541a303de9418854b3c2512ccbec
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/NOBNKLWKMJAHGLV6GVNITUBJ7OFJLIXY/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

2022-07-11 Thread Pablo Galindo Salgado

5/)-- Marking individual
TypedDict items as required or potentially-missing

(Hey, **fellow core developer,** if a feature you find important is
missing from this list, [let Pablo know](mailto:pablog...@python.org
).)

The next pre-release of Python 3.11 will be 3.11.0b5, currently scheduled
for Thursday, 2022-07-25.

# 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

The Planck temperature is 1.416784×10**32 K. At this temperature, the
wavelength of light emitted by thermal radiation reaches the Planck length.
There are no known physical models able to describe temperatures greater
than the Planck temperature and a quantum theory of gravity would be
required to model the extreme energies attained. Hypothetically, a system
in thermal equilibrium at the Planck temperature might contain Planck-scale
black holes, constantly being formed from thermal radiation and decaying
via Hawking evaporation; adding energy to such a system might decrease its
temperature by creating larger black holes, whose Hawking temperature is
lower.

Rumours say the Planck temperature can be reached in some of the hottest
parts of Spain in summer.

# We hope you enjoy the 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.

https://www.python.org/psf/

If you have any questions, please reach out to me or another member of the
release team :)

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/VD7YNBVMEPKZLRA6VOTYAQYTEZPDH6Q7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Starting the release of Python 3.11.0b4

2022-07-11 Thread Pablo Galindo Salgado

Hi everyone,

As a heads up: I'm starting the release of Python 3.11.0b4 and to avoid
complicating things I have
blocked the 3.11 branch until the release finishes so don't worry if you
are not able to merge stuff
in the 3.11 branch: nobody as removed your committer powers :)

Cheers from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YJXOZRTZDYEYY6N4BYPJUE3IG6C23CKN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [Release] Status of Python 3.11 release

2022-07-04 Thread Pablo Galindo Salgado

Hi everyone,

# TLDR

We may be pushing the final release until December if the stability of
Python 3.11 doesn't improve.

# Long Explanation

Unfortunately, we cannot still release the next Python 3.11 beta release
(3.11.0b4) because we still have a bunch
of pending release blockers. Unfortunately, this is still after several
preexisting release blockers have been fixed,
some of them being discovered after I sent my last update. These are the
current release blockers:

https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Arelease-blocker+label%3A3.11+

We also have some deferred blockers (some of them should actually be
release blockers):

https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Adeferred-blocker+label%3A3.11

Due to this and the fact that we are already 3 weeks delayed in the release
schedule, the current stability of Python 3.11 is not as good
as it is supposed to be at this stage of the release schedule and more
testing from end-users and library authors is required. After
discussing with the Steering Council, we are considering delaying the final
release until December to allow for two more beta releases.
This is how we are going to proceed:

* If the current release blockers are not fixed by the end of this week,
two more betas will be released (1 month per beta) and
we will *definitely* delay the final release until December.
* If the current release blockers are fixed we will proceed to release
Python 3.11.0b4 on Monday. We will target the current release
date (Monday, 2022-10-03) but if more release blockers that affect
fundamental parts of the Python interpreter or the standard libraries
are raised, the release team will still consider adding two more betas nd
pushing the final release to December.

One of the goals that we are going to try to achieve from the release team
is that no substantial code changes are added between the last
beta and the first release candidate. This is so all the fixes that affect
fundamental parts of the interpreter or the standard library can be
tested by end-users before the first release candidate is released (and not
with it). This is also partially because once we release the first release
candidate, the ABI will be frozen and certain kinds of fixes will be more
complicated.

Hopefully, this addresses some of you that have reached out with concerns
over the stability of Python 3.11 and the release schedule.

I understand that delaying the release until December will complicate
things for some Linux distributions and will affect end users and
redistributors
targeting the original release, but please understand that our
responsibility in the release team after all is to guarantee a stable final
release
above all and unfortunately, we don't currently have the confidence that we
would like given the current state of the release process.

Please do not hesitate in reaching out if you have any questions or
concerns.

Thanks, everyone for your help and understanding and thanks a lot to all of
you for your great work!

Cheers from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/3JWVCSBPBFWY5ZWSJ7RYB6FS5NIMCEOY/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [Release] Python 3.11.0b4 is still blocked

2022-06-24 Thread Pablo Galindo Salgado

Hi everyone,

A small update since the last communication from the release team regarding
the status of Python 3.11.0b4.

Unfortunately, even if we have fixed most of the original release blockers
and 4 more that appear during this week, we still have a bunch of release
blockers to deal with. One of them has been reported today.

I would like to release the next beta next week if everything looks good,
but there are also some items that need discussion:.

https://github.com/python/cpython/issues/93910

https://github.com/python/cpython/issues/93516

Ideally we should reach consensus as a team on how to proceed in these
issues. In particular, we should decide collectively what is an acceptable
slowdown, specially looking to the release candidate.

If releasing the next betas is further delayed, I will consider delaying
the full release schedule to accommodate for the delay so users have the
appropriate time to test and validate every release.

Please do not hesitate in reaching out if you have any questions or
concerns or if there is any issue you think we should include in the next
release.

Thanks everyone for your help and understanding. I'm sure 3.11 is going to
be an outstanding release thank to all of you :)

Cheers from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/7AT3YTUJOYMZI4VNMSJ42BE6ZNR7GANM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] IMPORTANT: Python 3.11.0b4 is blocked

2022-06-15 Thread Pablo Galindo Salgado

Hi everyone,

Today we are supposed to release Python3.11.0b4 but unfortunately, we have
a bunch of release blockers:

https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Arelease-blocker+label%3A3.11+

Please, if you are involved in the above issues check if they are resolved
or if they are not released blockers. If they are
not release blockers or you think we should defer them, please comment on
why on the issue. Also, please, notice that
the final decision to defer or not a blocker is made by the release
management team.

If you have some time to investigate, that will help a lot!

Please, add me as a reviewer to any PR that needs to be merged to address
these issues.

Thanks for your help!

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/ORCYBRP432J36LXP32IDX6KLRE7Z646V/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.5 is available

2022-06-06 Thread Pablo Galindo Salgado

The latest bugfix drop for Python 3.10 is here: Python 3.10.5. This release
packs more than 230 bugfixes and docs changes, so you surely want to update
:) You can get it here:

https://www.python.org/downloads/release/python-3105/

## This is the fourth maintenance release of Python 3.10

Python 3.10.5 is the newest major release of the Python programming
language, and it contains many new features and optimizations.

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

Among the new major new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and
prepare for the removal of the wstr member in PyUnicodeObject.
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial
* [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL
1.1.1 or newer
* [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove
Py_UNICODE encoder APIs
* [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional
EncodingWarning

[bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to
be on this list
in previous pre-releases but it has been postponed to Python 3.11 due to
some compatibility concerns. You can read the Steering Council
communication about it [here](
https://mail.python.org/archives/list/python-...@python.org/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/)
to learn more.

# More resources

* [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog
)
* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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
Strange quarks are the third lightest quarks, which are subatomic particles
that are so small,  they are believed to be the fundamental particles, and
not further divisible. Like down quarks, strange quarks have a charge of
-1/3. Like all fermions (which are particles that can not exist in the same
place at the same time), strange quarks have a spin of 1/2. What makes
strange quarks different from down quarks–apart from having 25 times the
mass of down quarks–is that they have something that scientists call
"strangeness." Strangeness is basically a resistance to decay against
strong force and electromagnetism. This means that any particle that
contains a strange quark can not decay due to strong force (or
electromagnetism), but instead with the much slower weak force. It was
believed that this was a 'strange' method of decay, which is why the
scientists gave the particles that name.

# We hope you enjoy the 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.

https://www.python.org/psf/

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/V4AUICXW2EDGFK2EIDSFA6RXMNWLCC54/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Expedited release of Python3.11.0b3!!

2022-06-01 Thread Pablo Galindo Salgado

Hi everyone,

Due to a known incompatibility with pytest and the previous beta release
(Python 3.11.0b2) and after
some deliberation, me and the rest of the release team have decided to do
an expedited release of
Python 3.11.0b3 so the community can continue testing their packages with
pytest and therefore
testing the betas as expected.

# Where can I get the new release?

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

# What happened?

Pytest by default rewrites the AST nodes in the testing code to provide
better diagnostics when something
fails in the test. For doing this, it creates new AST nodes that are then
compiled. In Python 3.11, after some
changes in the compiler and AST nodes, these new AST nodes that pytest was
creating were invalid. This causes
CPython to crash in debug mode because we have several assert statements in
the compiler, but in release mode
this doesn't cause always a crash, but it creates potential corrupted
structures in the compiler silently.

In 3.11.0b3 we changed the compiler to reject invalid AST nodes, so what
was a silent problem and a crash in
debug mode turned into an exception being raised. We had a fix to allow the
nodes that pytest is creating to work
to preserve backwards compatibility but unfortunately, it didn't make it
into 3.11.0b2.

Is still possible to use pytest with 3.11.0b2 if you add "--assert=plain"
to the pytest invocation but given how many
users would have to modify their test suite invocation we decided to
proceed with a new release that has the fix.

# What happens with future beta releases

Python 3.11.0b3 should be considered as an extra beta release. Instead of
four beta releases, we will have five and
the next beta release (3.11.0b4) will happen as scheduled on Thursday,
2022-06-16.

# We hope you enjoy the 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.

https://www.python.org/psf/

If you have any questions, please reach out to me or another member of the
release team :)

Your friendly release team,

Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YWAX3PNIXA6RDE2CGMGWZBFAAOM2LBA7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

2022-05-31 Thread Pablo Galindo Salgado

Does anyone want bug fixes? Because we have 164 new commits fixing
different things, from code to documentation. If you have reported some
issue after 3.11.0b1, you should check if is fixed and if not, make sure
you tell us so we can take a look. We still have two more betas to go so
help us to make sure we don't miss anything so everything is ready for the
final release!!

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

## This is a beta preview of Python  3.11

Python 3.11 is still in development. 3.11.0b2 is the second of four planned
beta release previews. Beta release previews are intended to give the wider
community the opportunity to test new features and bug fixes and to prepare
their projects to support the new feature release.

We **strongly encourage** maintainers of third-party Python projects to
**test with 3.11** during the beta phase and report issues found to [the
Python bug tracker](https://github.com/python/cpython/issues) as soon as
possible.  While the release is planned to be feature complete entering the
beta phase, it is possible that features may be modified or, in rare cases,
deleted up until the start of the release candidate phase (Monday,
2021-08-02).  Our goal is to have no ABI changes after beta 4 and as few
code changes as possible after 3.11.0rc1, the first release candidate.  To
achieve that, it will be **extremely important** to get as much exposure
for 3.11 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

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

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
* [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support
for Parsing TOML in the Standard Library
* [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal
String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual
TypedDict items as required or potentially-missing
* [PEP 681](https://www.python.org/dev/peps/pep-0681/)-- Data Class
Transforms
* [bpo-46752](https://bugs.python.org/issue46752)-- Introduce task groups
to asyncio
* [bpo-433030](https://github.com/python/cpython/issues/34627/) -- Atomic
grouping ((?>...)) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are
now supported in regular expressions.
* The [Faster Cpython Project](https://github.com/faster-cpython/) is
already yielding some exciting results. Python 3.11 is up to 10-60% faster
than Python 3.10. On average, we measured a 1.22x speedup on the standard
benchmark suite. See [Faster CPython](
https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details.
* (Hey, **fellow core developer,** if a feature you find important
is missing from this list, [let Pablo know](mailto:pablog...@python.org
).)

The next pre-release of Python 3.11 will be 3.11.0b3, currently scheduled
for Thursday, 2022-06-16.

# 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

The Planck time is the time required for light to travel a distance of 1
Planck length in a vacuum, which is a time interval of approximately
`5.39*10^(−44)` s. No current physical theory can describe timescales
shorter than the Planck time, such as the earliest events after the Big
Bang, and it is conjectured that the structure of time breaks down on
intervals comparable to the Planck time. While there is currently no known
way to measure time intervals on the scale of the Planck time, researchers
in 2020 found that the accuracy of an atomic clock is constrained by
quantum effects on the order of the Planck time, and for the most precise
atomic clocks thus far they calculated that such effects have been ruled
out to around `10^−33` s, or 10 orders of magnitude above the Planck scale.

# We hope you enjoy the 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.

https://www.python.org/psf/

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-commi

[python-committers] [RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here

2022-05-07 Thread Pablo Galindo Salgado

 of
the entropy larger than those allowed by an area law, hence in principle
larger than those of a black hole. These are the so-called "Wheeler's bags
of gold". The existence of such solutions conflicts with the holographic
interpretation, and their effects in a quantum theory of gravity including
the holographic principle are not fully understood yet.

# We hope you enjoy the 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.

https://www.python.org/psf/

Regards from chilly London,
Your friendly release team,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/7OR4SFLN4LLXQW3KHDHA6POAX5TBSTVM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Release of Python 3.11 beta 1 is currently blocked

2022-05-06 Thread Pablo Galindo Salgado

I should have started this email with "Nobody expects the Spanish
inquisition" :)

On Fri, 6 May 2022 at 13:13, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> Today we need to start the release of Python 3.11 beta 1. Currently, we
> have the following blockers:
>
> * https://github.com/python/cpython/issues/91162 (was deferred blocker -
> but all deferred blockers are bumped to release blockers on beta1).
> * https://github.com/python/cpython/issues/91350
> * We have 3 buildbots failing:
> https://buildbot.python.org/all/#/release_status (some of the failures
> are due to flaky tests but others look real).
>
> Please, if you are involved in the above issues check if they are resolved
> or if they are not released blockers (notice any semantic change, API
> change,
> public data structure change or grammar change must be done before beta 1
> is released). I will look at the buildbots later today but if you have some
> time to investigate, that would help a lot!
>
> *I am blocking the main branch so only the release team can merge changes*
> until these problems are addressed and we can continue with the release.
>
> Please, add me as a reviewer to any PR that needs to be merged to address
> these issues or any other change that *absolutely needs to go into beta 1*.
>
> Thanks for your help!
>
> Regards from sunny London,
> Pablo Galindo Salgado
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/I2NI4VW33O5J5WI3UANJK2QNFWOQCQ4T/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Release of Python 3.11 beta 1 is currently blocked

2022-05-06 Thread Pablo Galindo Salgado

Hi everyone,

Today we need to start the release of Python 3.11 beta 1. Currently, we
have the following blockers:

* https://github.com/python/cpython/issues/91162 (was deferred blocker -
but all deferred blockers are bumped to release blockers on beta1).
* https://github.com/python/cpython/issues/91350
* We have 3 buildbots failing:
https://buildbot.python.org/all/#/release_status (some of the failures are
due to flaky tests but others look real).

Please, if you are involved in the above issues check if they are resolved
or if they are not released blockers (notice any semantic change, API
change,
public data structure change or grammar change must be done before beta 1
is released). I will look at the buildbots later today but if you have some
time to investigate, that would help a lot!

*I am blocking the main branch so only the release team can merge changes*
until these problems are addressed and we can continue with the release.

Please, add me as a reviewer to any PR that needs to be merged to address
these issues or any other change that *absolutely needs to go into beta 1*.

Thanks for your help!

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YQAE62CAEASIBGHQ5LQZKT3JZ4BVIYKJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: 3.11 feature freeze coming up?

2022-05-05 Thread Pablo Galindo Salgado

Is an undetermined time on Friday, that makes it more exciting :)

On Thu, 5 May 2022 at 16:27, Paul Ganssle  wrote:

> Is this AoE time or London time?
>
> My last set of changes is kinda coming down to the wire 😬
>
> On May 5, 2022 10:02:46 AM UTC, Pablo Galindo Salgado 
> wrote:
>>
>> Hi Ethan,
>>
>> Sorry for the late reply (I was travelling back from PyCon and recovering
>> from the jet lag)!
>>
>> Feature freeze is still scheduled for Friday, 2022-05-06. If there are
>> release blockers or other problems it may take some extra days but I will
>> announce it here and probably block the main branch until is resolved.
>>
>> Cheers!
>>
>> On Tue, 3 May 2022 at 02:14, Ethan Furman  wrote:
>>
>>> Is this still scheduled for Thursday?
>>>
>>> --
>>> ~Ethan~
>>> ___
>>> python-committers mailing list -- python-committers@python.org
>>> To unsubscribe send an email to python-committers-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-committers@python.org/message/Y5COO4UVIPY3MRQJJGYIAYEBWRTEEEGO/
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YVECUZWPAAVKV3SZRPDPGWWEIOCQHP33/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: 3.11 feature freeze coming up?

2022-05-05 Thread Pablo Galindo Salgado

Hi Ethan,

Sorry for the late reply (I was travelling back from PyCon and recovering
from the jet lag)!

Feature freeze is still scheduled for Friday, 2022-05-06. If there are
release blockers or other problems it may take some extra days but I will
announce it here and probably block the main branch until is resolved.

Cheers!

On Tue, 3 May 2022 at 02:14, Ethan Furman  wrote:

> Is this still scheduled for Thursday?
>
> --
> ~Ethan~
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/Y5COO4UVIPY3MRQJJGYIAYEBWRTEEEGO/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/DSBOONBDXYZBWOZPLMN7ZDDXBXECWU24/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Erlend Aasland

2022-04-23 Thread Pablo Galindo Salgado

Hi everyone,

I have opened a poll to promote Erlend Aasland as a core developer.  Please
read more and vote here:

https://discuss.python.org/t/vote-to-promote-erlend-aasland/15246/2

Thank you!

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SOD6S6NRBJY7YWQYDYTATTS2BKJMF6TX/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-06 Thread Pablo Galindo Salgado

Hi everyone,

We have approximately one month until feature freeze and for 3.11.0b1 to be
released. I wanted to take this time to share some planning
and considerations with you. Please, read carefully these points as they
are important.

* 3.11.0b1 is scheduled for Friday, 2022-05-06, which is after the PyCon US
sprints. As the sprints normally end with a considerable
amount of PRs getting merged and the buildbots having a hard time, I may
need to move the release before or after to accommodate
for this and to prevent the release from going haywire. I will share
updates with you as they become available.

* The latest alpha releases have been quite challenging. We had a
considerable number of release blockers and issues that were raised
just a couple of days before the release. Please, check the release
blockers on bpo/Github as much as you can and make sure these are resolved
before the release date. Any release blockers for 3.11 will block feature
freeze. If this happens, the main branch will be blocked and only
PRs fixing the blockers will be allowed in that time.

* Important!! Please, if you are planning to commit a big chunk of code/ a
new big refactor/ a new big feature/ a PEP implementation within this month,
please let me know (an email works) so we can be on top of things in the
release team and so I can keep an eye on regressions.

* Any regression at the time of beta freeze will potentially result in the
release team being forced to revert commits and PRs. This means that if we
need
to revert a new feature or similar it may be delayed to 3.12, so be sure to
not commit unstable code as much as is humanly possible.

Please, reach out to me if you have any questions, comments or if you want
to discuss anything.

I want to thank you all for your understanding and collaboration :)

Kind regards from rainy London,
Your friendly release team
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/NCAQXXV6MYP24V6WO4BUC4Y7BZK4FM7D/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [RELEASE] The last Python 3.11 alpha (3.11.0a7) is available - Prepare for beta freeze

2022-04-06 Thread Pablo Galindo Salgado

A small correction (is fixed in other announcement pages):

The Faster Cpython Project is already yielding some exciting results: this
> version of CPython 3.11 is *~ 19%* faster on the geometric mean of the
> performance benchmarks, compared to 3.10.0.


That is, is not 12% faster but 19% faster. More updated benchmarks will be
published on beta 1.

Apologies for the confusion.

Pablo Galindo Salgado

On Wed, 6 Apr 2022 at 11:29, Pablo Galindo Salgado 
wrote:

> Br. do you feel that? That's the chill of *beta freeze* coming
> closer. Meanwhile, your friendly CPython release team doesn’t
> rest and we have prepared a shiny new release for you: Python 3.11.0a7.
>
>
> 
> Dear fellow core developer:
> This alpha is the last release before feature freeze (Friday, 2022-05-06),
> so make sure that all new features and PEPs are landed in the master branch
> before we
> release the first beta. Please, be specially mindfully to check the CI and
> the buildbots, maybe even using the test-with-buildbots label in GitHub
> before
> merging so the release team don’t need to fix a bunch of reference leaks
> or platform-specific problems on the first beta release.
>
> 
>
>
> *Go get the new alpha here:*
> https://www.python.org/downloads/release/python-3110a7/
>
> **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.0a7 is the last
> 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
> * [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support
> for Parsing TOML in the Standard Library
> * [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary
> Literal String Type
> * [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking
> individual TypedDict items as required or potentially-missing
> * [bpo-46752](https://bugs.python.org/issue46752)-- Introduce task groups
> to asyncio
> * 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.0b1, currently scheduled
> for Friday, 2022-05-06.
>
> # 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 mathematics, the Dirac delta distribution (δ distribution) is a
> generalized function or distribution over the real numbers, whose value is
> zero everywhere except at zero, and whose integral over the entire real
> line is equal to one. The current understanding of the impulse is as a
> linear functional that maps every continuous function to its value at zero.
> The delta function was introduced by physicist Paul Dirac as a tool for the
> normalization of state vectors. It also has uses in probability theory and
> signal processing. Its validity was disputed until Laurent Schwartz
> developed the theory of distributions where it is defined as a linear form
> acting on functions. Defining this distribu

[python-committers] [RELEASE] The last Python 3.11 alpha (3.11.0a7) is available - Prepare for beta freeze

2022-04-06 Thread Pablo Galindo Salgado

Br. do you feel that? That's the chill of *beta freeze* coming
closer. Meanwhile, your friendly CPython release team doesn’t
rest and we have prepared a shiny new release for you: Python 3.11.0a7.

Dear fellow core developer:
This alpha is the last release before feature freeze (Friday, 2022-05-06),
so make sure that all new features and PEPs are landed in the master branch
before we
release the first beta. Please, be specially mindfully to check the CI and
the buildbots, maybe even using the test-with-buildbots label in GitHub
before
merging so the release team don’t need to fix a bunch of reference leaks or
platform-specific problems on the first beta release.

*Go get the new alpha here:*
https://www.python.org/downloads/release/python-3110a7/

**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.0a7 is the last 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
* [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support
for Parsing TOML in the Standard Library
* [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal
String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual
TypedDict items as required or potentially-missing
* [bpo-46752](https://bugs.python.org/issue46752)-- Introduce task groups
to asyncio
* 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.0b1, currently scheduled
for Friday, 2022-05-06.

# 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 mathematics, the Dirac delta distribution (δ distribution) is a
generalized function or distribution over the real numbers, whose value is
zero everywhere except at zero, and whose integral over the entire real
line is equal to one. The current understanding of the impulse is as a
linear functional that maps every continuous function to its value at zero.
The delta function was introduced by physicist Paul Dirac as a tool for the
normalization of state vectors. It also has uses in probability theory and
signal processing. Its validity was disputed until Laurent Schwartz
developed the theory of distributions where it is defined as a linear form
acting on functions. Defining this distribution as a "function" as many
physicist do is known to be one of the easier ways to annoy mathematicians
:)

# 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-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/L42CSIJJBZRDC5UTXI4BXBT2KQ2HHPCI/
Code of Conduct: https://www.python.o

[python-committers] Candidates for next release manager

2022-03-15 Thread Pablo Galindo Salgado

Hi,

As Python 3.11.0 beta 1 approaches, we need to start considering the new
release manager.

*If you are interested in being the release manager for Python 3.12 (and
potentially Python 3.13*
*if you wish), please reach out to me.*

Ok, but what does a release manager do?

* The release manager is in charge of doing all the Python releases
associated with the versions that they
are in charge of. This includes normally 7 alphas, 4 betas, 2 release
candidates, final versions, bugfix
releases every 2 months for approximately 18 months and any source-only
security releases for 5 years
after the release of the final version. *This means that this is a
commitment of at least 5 years. *To get
an idea of what's involved in a release, check PEP 101
<https://peps.python.org/pep-0101/>.

* The release manager is in charge of ensuring that the releases are
stable. This means continuous monitoring
of the buildbots, shepherding some issues and release blockers, performance
degradation and many other aspects.
This means that is very important for the release manager to keep track of
the technical details of the development
of the versions they are in charge of.

* The release manager needs to ensure that release blockers are identified
and fixed before the releases are done. This
includes coordinating core developers to fix the release blockers or revert
the relevant changes in cases fixes are not
available in a reasonable amount of time.

* The release manager needs to author and maintain the release schedule
PEPs. Check PEP 664 <https://peps.python.org/pep-0664/> as an example.

* The release manager needs to ensure the "What's new" document for the
releases they are in charge of
is complete and properly reflects all changes, highlights and additions
that are included in the release. This could be
done personally by the release manager or coordinated by them.

If you have any questions, please reach out to me (or any other release
manager if you want) and we will be happy
to answer them :)

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/5KN4GUV7SEHNAM2P4JIEW6236IZYJJ6R/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11.0a6 is available

2022-03-07 Thread 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.

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

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

# More resources

# 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!

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/LM22QZ4WYXJ6HDSBP33X22BTJF7GJYIZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Python 3.11.0a6 is blocked

2022-03-03 Thread Pablo Galindo Salgado

Update: Seems that the refleaks have been fixed by Inada-san in this commit:

https://github.com/python/cpython/commit/3241cba4ec55ef0b9e73bf7a5a77ef29ae4b8756

I will wait until the buildbots are green and then try to proceed with the
release.

Thanks!

On Thu, 3 Mar 2022 at 20:14, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> Unfortunately, the release of 3.11.0a6 is still blocked because all
> reflect buildbots are failing:
>
> https://buildbot.python.org/all/#/release_status
>
> I will try to identify the commit(s) that introduced the regression and
> revert them, but for the
> time being the release is on hold, sadly.
>
> Regards from rainy Salamanca,
> Pablo Galindo Salgado
>
> On Wed, 2 Mar 2022 at 14:52, Pablo Galindo Salgado 
> wrote:
>
>> Hi everyone,
>>
>> Unfortunately, we have some issues marked as release blockers that are
>> holding the 3.11.0a6 release.
>> Some of these issues have been solved but we still have a couple of them.
>> Hopefully, we will solve these
>> soon and I will proceed with the release.
>>
>> Thanks for your understanding.
>>
>> Regards from sunny Salamanca,
>> Pablo Galindo Salgado
>>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/HO62U6PSAAJTLBMN2PH7ZNXFJK5IXBRF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Python 3.11.0a6 is blocked

2022-03-03 Thread Pablo Galindo Salgado

Hi everyone,

Unfortunately, the release of 3.11.0a6 is still blocked because all reflect
buildbots are failing:

https://buildbot.python.org/all/#/release_status

I will try to identify the commit(s) that introduced the regression and
revert them, but for the
time being the release is on hold, sadly.

Regards from rainy Salamanca,
Pablo Galindo Salgado

On Wed, 2 Mar 2022 at 14:52, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> Unfortunately, we have some issues marked as release blockers that are
> holding the 3.11.0a6 release.
> Some of these issues have been solved but we still have a couple of them.
> Hopefully, we will solve these
> soon and I will proceed with the release.
>
> Thanks for your understanding.
>
> Regards from sunny Salamanca,
> Pablo Galindo Salgado
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/L5HIYXRWAL7YPM7WIHBRFJ4GG4IVJ6LI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Python 3.11.0a6 is blocked

2022-03-02 Thread Pablo Galindo Salgado

Hi everyone,

Unfortunately, we have some issues marked as release blockers that are
holding the 3.11.0a6 release.
Some of these issues have been solved but we still have a couple of them.
Hopefully, we will solve these
soon and I will proceed with the release.

Thanks for your understanding.

Regards from sunny Salamanca,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TJCBPZNLSWQU2OX63CTWS2SHEJQN6P37/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [Python-Dev] [RELEASE] Python 3.11.0a5 is available

2022-02-04 Thread Pablo Galindo Salgado

Hi Mark,

Apologies, I forgot to update the numbers in the text :(

I will update them in all places where I can edit the text (download page
and discourse).

Thanks for pointing that out!

Cheers from sunny London,
Pablo

On Fri, 4 Feb 2022, 15:13 Mark Shannon,  wrote:

> Hi Pablo,
>
> On 03/02/2022 11:27 pm, Pablo Galindo Salgado wrote:
> > We needed to tame some angry buildbots, but after a small fight, we won
> with just some scratches! Here you have a shiny new alpha release: Python
> 3.11.0a5.
> >
> > https://www.python.org/downloads/release/python-3110a5/ <
> https://www.python.org/downloads/release/python-3110a5/>
> >
> > **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.0a5 is the
> fifth 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/ <
> 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/ <
> https://www.python.org/dev/peps/pep-0654/>) -- Exception Groups and
> except*
> > * [PEP 673](https://www.python.org/dev/peps/pep-0673/ <
> https://www.python.org/dev/peps/pep-0673/>)  -- Self Type
> > * [PEP 646](https://www.python.org/dev/peps/pep-0646/) <
> https://www.python.org/dev/peps/pep-0646/)>-- Variadic Generics
> > * The [Faster Cpython Project](https://github.com/faster-cpython <
> 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 <
> http://speed.python.org/>), compared to 3.10.0.
>
> Only 12%? Did you measure this on the same machine as usual?
> My measurements show a geometric mean of ~19%, although the range is -2%
> to +71%.
> I would just say "about 20%". 19% (or 12%) suggests rather more precision
> than is justifiable.
>
> Cheers,
> Mark.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SV5U76UCTO6HL7L4P7NTP535VKMAPBS5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11.0a5 is available

2022-02-03 Thread Pablo Galindo Salgado

We needed to tame some angry buildbots, but after a small fight, we won
with just some scratches! Here you have a shiny new alpha release: Python
3.11.0a5.

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

**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.0a5 is the fifth
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.

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

The next pre-release of Python 3.11 will be 3.11.0a6, currently scheduled
for Monday, 2022-02-28.

# More resources

# And now for something completely different

In physics, the Poynting vector (Umov-Poynting vector) represents the
directional energy flux (the energy transfer per unit area per unit time)
or power flow of an electromagnetic field. It is named after its discoverer
John Henry Poynting who first derived it in 1884. Oliver Heaviside also
discovered it independently in the more general form that recognises the
freedom of adding the curl of an arbitrary vector field to the definition.
The Poynting vector is used throughout electromagnetics in conjunction with
Poynting’s theorem, the continuity equation expressing conservation of
electromagnetic energy, to calculate the power flow in electromagnetic
fields.

# We hope you enjoy those new releases!

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/S4UDXUMVUHMEE36TBFAJPNTJF4TEUYPX/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Blocking the main branch due to too many buildbots failing

2022-01-28 Thread Pablo Galindo Salgado

Hi everyone,

We have a huge amount of buildbots failing and seems to be related to
different issues
that keep piling up. To prevent this from going worse,* I am blocking the
main branch*
*until these issues are resolved.*

Only release managers and the developer in residence will be able to merge
pull requests
until these issues are fixed. Please, ping me if you have a pull request
for fixing any of these
issues so we can merge.

I apologize for the inconvenience.

Thanks for your understanding,

Regards from rainy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/HU2LH5MX44QZXZ36YS4SOG4ZUPT4E7QT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Refleak tests in CI

2022-01-28 Thread Pablo Galindo Salgado

> Is there a possible middle ground here? Rather than a required PR check
(or a full buildbot run), maybe we could just add a new “magic” label that
runs a single refleak job using the GitHub actions runners.

That sounds like a good compromise and it will be strictly better than the
current setup.

In addition, I still think that for the slower tests, the git diff based
test run can be quite beneficial.

We just need to bear in mind that those tests will always be partial, so we
should not be surprised if refleaks are still detected in buildbots.

On Fri, 28 Jan 2022 at 14:25, Brandt Bucher  wrote:

> Is there a possible middle ground here? Rather than a required PR check
> (or a full buildbot run), maybe we could just add a new “magic” label that
> runs a single refleak job using the GitHub actions runners.
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/NZ4N276GWJVCPU2VL2EDFTYUXWU4WCHR/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/6LQSZLJ5QTB6732TDMCNEACTY6FKNUIP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Refleak tests in CI

2022-01-28 Thread Pablo Galindo Salgado

>
> > It is nigh impossible to pick out errors in a PR from flaky tests,
> flaky machines and pre-existing errors.

I agree with the sentiment but is certainly not that dramatic. We (people
watching the build bots) do it on a regular basis, and many contributors do
it very efficiently as well. I agree that flaky tests and machines do not
help here, but those are generally just a small subset (although a noisy
one). Pre-existing errors should be fixed, so one could argue that these
errors being annoying is a positive thing under some optics.

I think the best approach for a CI check is to link every source file to a
particular test and then use the diff to select what tests to run. Notice
this is still not enough because some tests (like test_asyncio) will take a
huge amount of time on their own in refleak mode.

Additionally, some files will virtually touch all tests (like changing the
VM) and some refleaks will only be visible with an unknown subset of them.

I would rather have to wait a while to merge good code, than merge bad code
> quickly.

With that logic, seems that waiting for buildbots is not bad ;)

On Fri, 28 Jan 2022 at 11:46, Mark Shannon  wrote:

> Hi,
>
> We don't have a PR check for refleaks. I would like one.
>
> The buildbots are far too slow and unreliable to provide a sensible way to
> check for refleaks.
> It is nigh impossible to pick out errors in a PR from flaky tests, flaky
> machines and pre-existing errors.
>
> Stopping refleaks at source would be great. But we need a PR checks for
> refleaks.
>
> Unfortunately, refleaks tests are currently very slow.
> By splitting the tests into 3 or 4 groups we should be able to run refleak
> tests without slowing turn around too much.
>
> I would rather have to wait a while to merge good code, than merge bad
> code quickly.
> I don't think the cost would be prohibitive.
>
> Cheers,
> Mark.
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/4LX4K2OFBXW54O2WLNXJMXL6242TZSTX/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UTCTHQHELKDACGJF4OBJQ47WXTMOCFSL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Status of Python 3.11.0a4

2022-01-11 Thread Pablo Galindo Salgado

Hi everyone,

I want to report on the status of Python 3.11.0a4. We had a ton of release
blockers (some extra ones
since I reported the last time) and it seems that we managed to fix them
all (thanks to Mark Shannon,
Christian Heimes, Gregory P. Smith, Neil Schemenauer, Steve Dower and many
others that helped with
the blockers.

Unfortunately it seems that the release is cursed and we are having some
problems with the certificates
to create and sign the Windows artefacts so we are waiting for that to
unblock us.

I will keep you posted on new developments.

Regards from rainy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/RZ7EJU66R5J3IMVCPP43ICZ23SQZNCP5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Python 3.11.0a4 is blocked

2022-01-06 Thread Pablo Galindo Salgado

Hi everyone,

An update on this. Unfortunately, we are still blocked. Some of the
blockers have been fixed (thanks to everyone involved) but the following
are still pending:

* https://bugs.python.org/issue46208

This issue has a PR being reviewed but the fix is still not merged.

* https://bugs.python.org/issue46006

Victor made a revert of his PR but unfortunately, we cannot easily backport
it to 3.10 as it affects the ABI. It affects the interpreter state
structure that although is not on the stable ABI, changing it can affect
some projects so we need to discuss how we want to proceed as a project
here.

* https://bugs.python.org/issue46263

One of the FreeBSD issues has been fixed (thanks Christian) but another
issue has been unveiled (some problem in test_capi) and the other one still
lingers (test_embed failing due to freezing modules).

Thanks for all your help,

Kind regards from cloudy London,
Pablo Galindo Salgado

On Tue, 4 Jan 2022 at 23:12, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> I am writing this to notify you that unfortunately the release of 3.11.0a4
> is blocked as there are a bunch of release blockers
> (some of them affect Python 3.10):
>
> https://bugs.python.org/issue46263
> https://bugs.python.org/issue46208
> https://bugs.python.org/issue46006
> https://bugs.python.org/issue43683
>
> If this was a single release blocker I would think about moving
> forward but unfortunately, there are several of them and one of
> them is that Python fails to compile FreeBSD, so I am halting the release
> until these are fixed.
>
> Regards from rainy London,
> Pablo Galindo Salgado
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UCGWU4VTU6YM63CQKMBROVEYOGW6CKWR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Python 3.11.0a4 is blocked

2022-01-04 Thread Pablo Galindo Salgado

Hi everyone,

I am writing this to notify you that unfortunately the release of 3.11.0a4
is blocked as there are a bunch of release blockers
(some of them affect Python 3.10):

https://bugs.python.org/issue46263
https://bugs.python.org/issue46208
https://bugs.python.org/issue46006
https://bugs.python.org/issue43683

If this was a single release blocker I would think about moving forward but
unfortunately, there are several of them and one of
them is that Python fails to compile FreeBSD, so I am halting the release
until these are fixed.

Regards from rainy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/7OWGAL4UL5HNKKQFUGH6N6L4JDVPEN7R/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11.0a3 is available

2021-12-08 Thread Pablo Galindo Salgado

You can tell that we are slowly getting closer to the first beta as the
number of release blockers that we need to fix on every release starts to
increase [image: :sweat_smile:] But we did it! Thanks to Steve Dower, Ned
Deily, Christian Heimes, Łukasz Langa and Mark Shannon that helped get
things ready for this release :)

Go get the new version here:

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

**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.0a3 is the third
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.

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*
* 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.0a4, currently scheduled
for Monday, 2022-01-03.

# More resources

# And now for something completely different

Rayleigh scattering, named after the nineteenth-century British physicist
Lord Rayleigh is the predominantly elastic scattering of light or other
electromagnetic radiation by particles much smaller than the wavelength of
the radiation. For light frequencies well below the resonance frequency of
the scattering particle, the amount of scattering is inversely proportional
to the fourth power of the wavelength. Rayleigh scattering results from the
electric polarizability of the particles. The oscillating electric field of
a light wave acts on the charges within a particle, causing them to move at
the same frequency. The particle, therefore, becomes a small radiating
dipole whose radiation we see as scattered light. The particles may be
individual atoms or molecules; it can occur when light travels through
transparent solids and liquids but is most prominently seen in gases.

The strong wavelength dependence of the scattering means that shorter
(blue) wavelengths are scattered more strongly than longer (red)
wavelengths. This results in the indirect blue light coming from all
regions of the sky.

# We hope you enjoy those new releases!

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/UJULODWK44IYR7HIITSBUQ75YC33FJUC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.1 is available

2021-12-06 Thread Pablo Galindo Salgado

I hope you like bug fixes, because we have a whole shipment of them! Python
3.10.1 is the first maintenance release of Python 3.10 as we have packed
more than 330 commits of fixes and general improvements. You can get it
here:

https://www.python.org/downloads/release/python-3101/

# This is the first maintenance release of Python 3.10

Python 3.10.1 is the newest major release of the Python programming
language, and it contains many new features and optimizations.

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

Among the new major new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and
prepare for the removal of the wstr member in PyUnicodeObject.
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial
* [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL
1.1.1 or newer
* [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove
Py_UNICODE encoder APIs
* [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional
EncodingWarning

[bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to
be on this list
in previous pre-releases but it has been postponed to Python 3.11 due to
some compatibility concerns. You can read the Steering Council
communication about it [here](
https://mail.python.org/archives/list/python-...@python.org/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/)
to learn more.

# More resources

* [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog
)
* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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

The Meissner effect (or Meissner–Ochsenfeld effect) is the expulsion of a
magnetic field from a superconductor during its transition to the
superconducting state when it is cooled below the critical temperature.
This expulsion will repel a nearby magnet. The German physicists Walther
Meissner and Robert Ochsenfeld discovered this phenomenon in 1933 by
measuring the magnetic field distribution outside superconducting tin and
lead samples. The experiment demonstrated for the first time that
superconductors were more than just perfect conductors and provided a
uniquely defining property of the superconductor state. The ability for the
expulsion effect is determined by the nature of equilibrium formed by the
neutralization within the unit cell of a superconductor.

You can do [ver cool things](https://www.youtube.com/watch?v=HRLvVkkq5GE)
with it!

# We hope you enjoy the 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.

https://www.python.org/psf/

Your friendly release team,
Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CFCZC5ZQFSQD3C32IKHO6SQSZHCWZTNC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.11.0a1 is available

2021-10-07 Thread Pablo Galindo Salgado

Now that we are on a release spree, here you have the first alpha release of
Python 3.11: Python 3.11.0a1. Let the testing and validation games begin!

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

*Major new features of the 3.11 series, compared with 3.10*

Python 3.11 is still in development. This release, 3.11.0a1 is the first of
six 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.

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 – Include
Fine-Grained Error Locations in Tracebacks
- PEP 654 – PEP 654 –
Exception Groups and except*
- (Hey, fellow core developer, if a feature you find important is
missing from this list, let Pablo know .)

The next pre-release of Python 3.11 will be 3.11.0a2, currently scheduled
for 2021-11-02.
*And now for something completely different*

Zero-point energy is the lowest possible energy that a quantum mechanical
system may have. Unlike in classical mechanics, quantum systems constantly
fluctuate in their lowest energy state as described by the Heisenberg
uncertainty principle. As well as atoms and molecules, the empty space of
the vacuum has these properties. According to quantum field theory, the
universe can be thought of not as isolated particles but as continuous
fluctuating fields: matter fields, whose quanta are fermions (i.e., leptons
and quarks), and force fields, whose quanta are bosons (e.g., photons and
gluons). All these fields have a non zero amount of energy called
zero-point energy. Physics currently lacks a full theoretical model for
understanding zero-point energy; in particular, the discrepancy between
theorized and observed vacuum energy is a source of major contention

*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.

Regards from cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/T4YIZDQWU23RQVPWAINIHUDBPGR7N3YQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Thanks for your work in Python 3.10

2021-10-05 Thread Pablo Galindo Salgado

Hi everyone,

Now that 3.10.0 is finally released I wanted to take the time to thank you
all for all your fantastic
work this past year. Is because of the sum of all your fantastic work that
Python 3.10 is going to be
such a fantastic release. No matter if you have been working in fixing
bugs, adding features,
improving the documentation, reviewing contributor PRs, helping with the
infrastructure, helping with
the buildbot fleet, triaging bugs or discussing PEPs and features, your
work is tremendously appreciated:
you make a tremendous impact in Python and its community.

I also wanted to make sure to thank again all the people that helped with
the release itself and with the
numerous release blockers and also for your patience when I had to delay
your feature to 3.11 or your
bugfix to 3.10.1.

It has been a privilege to be able to release the result of your work to
the community!

Thank you all, your work really makes a difference.

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YIZ4XLYW25UA3UVQLQHHIEYUK77ZE5XE/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0 is available

2021-10-04 Thread Pablo Galindo Salgado

On behalf of the Python development community and the Python 3.10 release
team, I’m pleased to announce the availability of Python 3.10.0.
Python 3.10.0 is the newest major release of the Python programming
language, and it contains many new features and optimizations.

https://www.python.org/downloads/release/python-3100/

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

Among the new major new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and
prepare for the removal of the wstr member in PyUnicodeObject.
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial
* [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL
1.1.1 or newer
* [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove
Py_UNICODE encoder APIs
* [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional
EncodingWarning

[bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to
be on this list
in previous pre-releases but it has been postponed to Python 3.11 due to
some compatibility concerns. You can read the Steering Council
communication about it [here](
https://mail.python.org/archives/list/python-...@python.org/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/)
to learn more.

# More resources

* [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog
)
* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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

For a Schwarzschild black hole (a black hole with no rotation or
electromagnetic charge), given a free fall particle starting at the event
horizon, the maximum propper time it will experience to fall into (which
happens when it falls without angular velocity) the singularity is `π*M`
(in [natural units](https://en.wikipedia.org/wiki/Natural_units)), where M
is the mass of the black hole. For Sagittarius A* (the black hole at the
center of the milky way) this time is approximately 1 minute.

Schwarzschild black holes are also unique because they have a space-like
singularity at their core, which means that the singularity doesn't happen
at a specific point in *space* but happens at a specific point in *time*
(the future). This means once you are inside the event horizon you cannot
point with your finger towards the direction the singularity is located
because the singularity happens in your future: no matter where you move,
you will "fall" into it.

# We hope you enjoy the 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.

https://www.python.org/psf/

# More resources

Online Documentation https://docs.python.org/3.10/
PEP 619 https://www.python.org/dev/peps/pep-0619/, 3.10 Release Schedule
Report bugs at https://bugs.python.org https://bugs.python.org/.
Help fund Python and its community https://www.python.org/psf/donations/.

Your friendly release team,
Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/OQWNWZWDPASOUOAT6VPUXIXBH2THYREC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0rc2 is available

2021-09-07 Thread Pablo Galindo Salgado

Python 3.10 is one month away, can you believe it? This snake is still
trying to bite as it has been an interesting day of fighting fires, release
blockers, and a bunch of late bugs but your friendly release team always
delivers :)

You can get this new release while is still fresh here:

https://www.python.org/downloads/release/python-3100rc2/

This is the second release candidate of Python 3.10

This release, **3.10.0rc2** , is the last preview before the final release
of Python 3.10.0 on 2021-10-04. Entering the release candidate phase, only
reviewed code changes which are clear bug fixes are allowed between release
candidates and the final release. There will be no ABI changes from this
point forward in the 3.10 series and the goal is that there will be as few
code changes as possible.

*The next release will be the final release of Python 3.10.0, which is
currently scheduled for Monday, 2021-10-04.*

Call to action
⚠️⚠️⚠️⚠️⚠️⚠️⚠️
*The 3.10 branch is now accepting changes for 3.10.**1*. To maximize
stability, the final release will be cut from the v3.10.0rc2 tag. If you
need the release manager (me) to cherry-pick any critical fixes, mark
issues as release blockers, and/or add me as a reviewer on a critical
backport PR on GitHub. To see which changes are currently cherry-picked for
inclusion in 3.10.0, look at the short-lived branch-v3.10.0
https://github.com/python/cpython/tree/branch-v3.10.0 on GitHub.
⚠️⚠️⚠️⚠️⚠️⚠️⚠️

*Core developers: all eyes on the docs now*

- Are all your changes properly documented?
- Did you notice other changes you know of to have insufficient
documentation?

*Community members*
We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.10 compatibilities during this phase. As always,
report any issues to [the Python bug tracker ](https://bugs.python.org/).

Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

And now for something completely different
Maxwell's demon is a thought experiment that would hypothetically violate
the second law of thermodynamics. It was proposed by the physicist James
Clerk Maxwell in 1867. In the thought experiment, a demon controls a small
massless door between two chambers of gas. As individual gas molecules (or
atoms) approach the door, the demon quickly opens and closes the door to
allow only fast-moving molecules to pass through in one direction, and only
slow-moving molecules to pass through in the other. Because the kinetic
temperature of a gas depends on the velocities of its constituent
molecules, the demon's actions cause one chamber to warm up and the other
to cool down. This would decrease the total entropy of the two gases,
without applying any work, thereby violating the second law of
thermodynamics.

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.

Regards from a plane going to Malaga,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/PKIM4YATUDGXNRD36QYXMDVJX5RJXP2J/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Dates for the core dev sprint 2021

2021-08-30 Thread Pablo Galindo Salgado

Hi,

>From the Steering Council, we would like to get some idea of everyone’s
availability for a potential core dev sprint this year. Given the current
world limitations on travelling and the time frame, it will have to be an
online core dev sprint like past year’s. Before any further work on this or
preparation, we need to determine a time frame for when it will happen so I
am opening this poll to find out about your availability so we can
determine the best time for everyone.

You can find the poll here:

https://discuss.python.org/t/dates-for-core-dev-sprint/10400

Regards from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/GC3A2LYWFCNYC2TVL2KATD6K5AMHFUOD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [RELEASE] Python 3.10.0rc1 is available

2021-08-04 Thread Pablo Galindo Salgado

Hi,

Unfortunately, due to a problem that I was not aware of caused by
https://bugs.python.org/issue44756, the
release artifacts for Linux contained a "venv" folder in the "Docs"
directory.

I have uploaded a new version of the artifacts that fixed this problem and
I have corrected this for future
releases.

If you had any problem building docs with the previous release artifacts
for 3.10.0rc1, please try again.

Regards from cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower

On Tue, 3 Aug 2021 at 17:31, Pablo Galindo Salgado 
wrote:

> Python 3.10.0 is almost ready. This release, 3.10.0rc1, is the
> penultimate release preview. You can get it here:
>
> https://www.python.org/downloads/release/python-3100rc1/
>
>
> *This is the first release candidate of Python 3.10*
> This release, **3.10.0rc1**, is the penultimate release preview.  Entering
> the release candidate phase, only reviewed code changes which are
> clear bug fixes are allowed between this release candidate and the final
> release. The second candidate and the last planned release preview is
> currently planned for 2021-09-06 while the official release is planned for
> 2021-10-04.
>
> There will be no ABI changes from this point forward in the 3.10 series
> and the goal is that there will be as few code changes as possible.
>
> *Call to action*
> Core developers: all eyes on the docs now
>
>- Are all your changes properly documented?
>- Did you notice other changes you know of to have insufficient
>documentation?
>
> Community members
>
> We strongly encourage maintainers of third-party Python projects to
> prepare their projects for 3.10 compatibilities during this phase. As
> always, report any issues to the Python bug tracker
> <https://bugs.python.org/>.
> Please keep in mind that this is a preview release and its use is **not**
> recommended for production environments.
>
> *And now for something completely different*
>
> In theoretical physics, quantum chromodynamics (QCD) is the theory of the
> strong interaction between quarks and gluons, the fundamental particles
> that make up composite hadrons such as the proton, neutron, and pion. The
> QCD analog of electric charge is a property called color. Gluons are the
> force carrier of the theory, just as photons are for the electromagnetic
> force in quantum electrodynamics. There are three kinds of charge in QCD
> (as opposed to one in quantum electrodynamics or QED) that are usually
> referred to as "color charge" by loose analogy to the three kinds of color
> (red, green and blue) perceived by humans. Other than this nomenclature,
> the quantum parameter "color" is completely unrelated to the everyday,
> familiar phenomenon of color.
>
>
> *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.
>
> Regards from cloudy London,
>
> Your friendly release team,
> Pablo Galindo @pablogsal
> Ned Deily @nad
> Steve Dower @steve.dower
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/DJTNV6AO4HJDLKL5FY3MQECC5BVFVZSB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0rc1 is available

2021-08-03 Thread Pablo Galindo Salgado

Python 3.10.0 is almost ready. This release, 3.10.0rc1, is the penultimate
release preview. You can get it here:

https://www.python.org/downloads/release/python-3100rc1/

*This is the first release candidate of Python 3.10*
This release, **3.10.0rc1**, is the penultimate release preview. Entering
the release candidate phase, only reviewed code changes which are
clear bug fixes are allowed between this release candidate and the final
release. The second candidate and the last planned release preview is
currently planned for 2021-09-06 while the official release is planned for
2021-10-04.

There will be no ABI changes from this point forward in the 3.10 series and
the goal is that there will be as few code changes as possible.

*Call to action*
Core developers: all eyes on the docs now

- Are all your changes properly documented?
- Did you notice other changes you know of to have insufficient
documentation?

Community members

We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.10 compatibilities during this phase. As always,
report any issues to the Python bug tracker .
Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

*And now for something completely different*

In theoretical physics, quantum chromodynamics (QCD) is the theory of the
strong interaction between quarks and gluons, the fundamental particles
that make up composite hadrons such as the proton, neutron, and pion. The
QCD analog of electric charge is a property called color. Gluons are the
force carrier of the theory, just as photons are for the electromagnetic
force in quantum electrodynamics. There are three kinds of charge in QCD
(as opposed to one in quantum electrodynamics or QED) that are usually
referred to as "color charge" by loose analogy to the three kinds of color
(red, green and blue) perceived by humans. Other than this nomenclature,
the quantum parameter "color" is completely unrelated to the everyday,
familiar phenomenon of color.

Regards from cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/LK3JXTWJ2D6JP6NBLFA44SLQOOLNHEV3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [IMPORTANT] [Release communication] Python 3.10.0rc1 next week: get ready!

2021-07-27 Thread Pablo Galindo Salgado

Hi everyone,

This is a friendly reminder from the release management team that the first
release candidate of Python 3.10 is
next Monday. Now is a fantastic time you make sure that:

## If you are a user or library developer

* If you filed a bug for something not working in any of the betas for
3.10, check that the bug is properly fixed.
* Ensure that your library/application works as expected with Python 3.10.
* Ensure that if your library needs to interact with the Python syntax or
type system, it works with the new additions in 3.10
<https://docs.python.org/3.10/whatsnew/3.10.html#summary-release-highlights>
.
* [Optional] Check that there are no performance regressions in your
application/library with Python 3.10

## If you are a core developer or a member of the triage team

* Merge or review any urgent bugfixes that you are interested in
* Your changes are properly documented.
* There isn't any critical bug in the tracker regarding a feature you
implemented/merged.
* If your change is relevant enough, it appears in the What's new document
<https://docs.python.org/3.10/whatsnew/3.10.html> (if you have doubts, you
can ask me ;) ).

Some technical details of the release candidate:

Once the 3.10 branch reaches RC status, it only can have bug fixes applied
that have been reviewed by
other core developers (so you cannot merge your own PR without review even
if you are a core dev). Generally, these issues
must be severe enough (e.g. crashes) that they deserve fixing before the
final release. All other issues should be deferred to
the next development cycle (Python 3.10.1) since stability is the strongest
concern at this point. Also bear in mind that
once we reach the RC, the *ABI is frozen* and cannot change even for bug
fixes.

While the goal is to have no code changes between an RC and a final
release, there may be a need for final documentation o
test fixes. Any such proposed changes should be discussed first with the
release manager.

*You cannot skip the peer review during an RC*, no matter how small! Even
if it is a simple copy-and-paste change,
everything requires peer review from a core developer.

(You can find these instructions and details in the devguide
<https://devguide.python.org/devcycle/#rc>).

Thank you all for your help!

Regards from rainy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/RLO5Y6FPOPUJAJVN6MHRIKUSMSRUXUT6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0b4 is available

2021-07-10 Thread Pablo Galindo Salgado

Wow! A release on a Saturday? Do the release management team even rest? You
better believe it, because this is the last of the planned beta releases.
This means that the next pre-release will be the first release candidate of
Python 3.10.0. Remember that our goal is to have no ABI changes after this
beta and a few code changes as possible after 3.10.0rc1.

https://www.python.org/downloads/release/python-3100b4/

#This is a beta preview of Python 3.10

Python 3.10 is still in development. 3.10.0b4 is the fourth and last of the
beta release previews. Beta release previews are intended to give the wider
community the opportunity to test new features and bug fixes and to prepare
their projects to support the new feature release.

We strongly encourage maintainers of third-party Python projects to test
with 3.10 during the beta phase and report issues found to the Python bug
tracker as soon as possible. While the release is planned to be feature
complete entering the beta phase, it is possible that features may be
modified or, in rare cases, deleted up until the start of the release
candidate phase (Monday, 2021-08-02). Our goal is to have no ABI changes
after beta 4 and as few code changes as possible after 3.10.0rc1, the first
release candidate. To achieve that, it will be extremely important to get
as much exposure for 3.10 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is not
recommended for production environments.

The next pre-release, the first release candidate of Python 3.10.0, will be
3.10.0rc1. It is currently scheduled for Monday, 2021-08-02.

#And now for something completely different

In quantum physics, the spin is an intrinsic form of angular momentum
carried by elementary particles, composite particles, and atomic nuclei.
The spin is one of two types of angular momentum in quantum mechanics, the
other being orbital angular momentum. The orbital angular momentum operator
is the quantum-mechanical counterpart to the classical angular momentum of
orbital revolution and appears when there is periodic structure to its
wavefunction as the angle varies. For photons, spin is the
quantum-mechanical counterpart of the polarization of light; for electrons,
the spin has no classical counterpart.

# We hope you enjoy those new releases!

Regards from very cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/7MKFRWB4XKMNKXVHSBYTQ6RM4ZUL45XJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0b3 is available

2021-06-17 Thread Pablo Galindo Salgado

Summer is almost here (at least in half of the planet) and Python 3.10 is
finishing baking in the oven. For those of you that want to taste it before
is finally ready (and if you are a library developer, you certainly do!)
you can have the second-to-last beta now, but be careful as is still very
hot ;)
https://www.python.org/downloads/release/python-3100b3/

#This is a beta preview of Python 3.10

Python 3.10 is still in development. 3.10.0b3 is the third of four planned
beta release previews. Beta release previews are intended to give the wider
community the opportunity to test new features and bug fixes and to prepare
their projects to support the new feature release.

Please keep in mind that this is a preview release and its use is not
recommended for production environments.

The next pre-release of Python 3.10 will be 3.10.0b4, currently scheduled
for Saturday, 2021-07-10.

#And now for something completely different

There are no green stars. Why? In general, objects don’t emit a single
wavelength of light when they shine. Instead, they emit photons in a range
of wavelengths. If you were to use some sort of detector that is sensitive
to the wavelengths of light emitted by an object, and then plotted the
number of them versus wavelength, you get a lopsided plot called a
blackbody curve. For an object as hot as the Sun, that curve peaks at
blue-green, so it emits most of its photons there. But it still emits some
that are bluer, and some that are redder. When we look at the Sun, we see
all these colors blended together. Our eyes mix them up to produce one
color: white. A warmer star will put out more blue, and a cooler one
redder, but no matter what, our eyes just won’t see that as green. Due to
how we perceive color, the only way to see a star as being green is for it
to be only emitting green light. But as starts always emit radiation
following the blackbody curve, that’s pretty much impossible.

# We hope you enjoy those new releases!

Regards from very cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/VNUESN72NYKV5DKM6GJ3WUFUS6DWVUSN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0b2 is available

2021-06-01 Thread Pablo Galindo Salgado

After fighting with some release blockers, implementing a bunch of GC
traversal functions, and fixing some pending reference leaks, we finally
have Python 3.10.0 beta 2 ready for you! Thanks to everyone that helped to
unblock the release!

https://www.python.org/downloads/release/python-3100b2/

# This is a beta preview of Python 3.10

Python 3.10 is still in development. 3.10.0b2 is the second of four planned
beta release previews. Beta release previews are intended to give the wider
community the opportunity to test new features and bug fixes and to prepare
their projects to support the new feature release.

We **strongly encourage** maintainers of third-party Python projects to
**test with 3.10** during the beta phase and report issues found to [the
Python bug tracker](https://bugs.python.org/) as soon as possible. While
the release is planned to be feature complete entering the beta phase, it
is possible that features may be modified or, in rare cases, deleted up
until the start of the release candidate phase (Monday, 2021-08-02). Our
goal is to have no ABI changes after beta 4 and as few code changes as
possible after 3.10.0rc1, the first release candidate. To achieve that, it
will be **extremely important** to get as much exposure for 3.10 as
possible during the beta phase.

Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

The next pre-release of Python 3.10 will be 3.10.0b3, currently scheduled
for Thursday, 2021-06-17.

# And now for something completely different

The Ehrenfest paradox concerns the rotation of a "rigid" disc in the theory
of relativity. In its original 1909 formulation as presented by Paul
Ehrenfest in relation to the concept of Born rigidity within special
relativity, it discusses an ideally rigid cylinder that is made to rotate
about its axis of symmetry. The radius R as seen in the laboratory frame is
always perpendicular to its motion and should therefore be equal to its
value R0 when stationary. However, the circumference (2πR) should appear
Lorentz-contracted to a smaller value than at rest. This leads to the
apparent contradiction that R = R0 and R < R0.

# We hope you enjoy those new releases!

Regards from very sunny London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/K24LNBMWJH6E6YKZK5PMAVEAQFPAPTYN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

> So, on what principled basis do we exempt, say, ints from
participating in cyclic GC too? Do we have to "just know" that a cycle
can't be reached from an int's type object? If so, is that even true?
Or just convenient to pretend to believe to avoid adding 16 more bytes
to each int object and grossly slowing gc scans in the presence of
many ints? ;-) If it is true, how do we know for which type objects it
is and isn't true?

In this case, the int object doesn't have a reference to its type because
is not a heap type
so that's fine. The problem appeared after the changes done in 3.8 to heap
types (https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api)


On Thu, 27 May 2021 at 23:12, Tim Peters  wrote:

> ;Victor Stinner ]
> > ...
> > For a more concrete example, read the "_thread lock traverse" section
> > of my article on these problems:
> > https://vstinner.github.io/subinterpreter-leaks.html
> >
> > There were two reference cycles, and both were "connected" with a lock
> > object in the middle (look at my drawing). The lock object was *not*
> > directly part of any ref cycle. But because it had no traverse
> > function, the GC failed to break both cycles in a single collection. A
> > second manual GC collection was needed to break the second cycles, to
> > *work around* the issue.
>
> Thanks! Let me correct/refine my characterization. For cyclic GC to
> work as intended, every object from which a cycle may be reached must
> participate in cyclic GC, and its tp_traverse must visit every
> contained object from which a cycle may be reached. Necessary and
> sufficient, there. Contrary to previous stabs, it's actually
> irrelevant whether the object may itself be directly in a cycle.  As
> in your example, it can do damage to the intent if an object is merely
> a (or just on an) acyclic bridge between cycles (even though not
> _itself_ in a cycle).
>
> So, if we're saying that type objects in general may be in cycles,
> then it's necessary that absolutely every object participate in GC,
> and its tp_traverse must visit absolutely every object it points to
> (every object points to a type object, as does every contained object
> likewise: there are potential cycles everywhere).
>
> So, on what principled basis do we exempt, say, ints from
> participating in cyclic GC too? Do we have to "just know" that a cycle
> can't be reached from an int's type object? If so, is that even true?
> Or just convenient to pretend to believe to avoid adding 16 more bytes
> to each int object and grossly slowing gc scans in the presence of
> many ints? ;-) If it is true, how do we know for which type objects it
> is and isn't true?
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/D5FJJIDM4KJA43FGZWZN4WRCMLQG724M/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

Tim, check this out:

>>> import re, gc
>>> x = re.compile("x")
>>> gc.get_referents(x.__class__)[-1]


That seems due to:

https://github.com/python/cpython/blob/e90e0422182f4ca7faefd19c629f84aebb34e2ee/Objects/typeobject.c#L4241


On Thu, 27 May 2021 at 20:15, Tim Peters  wrote:

> [Tim]
> >> And if a type pointer is the only thing being visited, then there's no
> point
> >> unless the object can itself be reachable from the type object.
>
> {Pablo]
> > But that could happen easily for heap types as they are mutable by
> > default. For instance, you set the instance in a global:
> >
> > type -> module -> globals -> instance -> type
>
> Sorry, but this is apparently a rat's nest and that's too sketchy for me
> ;-)
>
> Can you flesh this out for what stumbled into being my running
> example? That is, how could a regexp pattern object be part of a
> cycle?
>
> >>> import re
> >>> p = re.compile("ab*c")
> >>> type(p)
> 
> >>> type(p).__module__
> 're'
> >>> type(type(p).__module__)
> 
>
> That is, its __module__ attribute is a string, not a module object.
>
> And, in general, I can't add attributes to p, or change their bindings:
>
> >>> p.flags
> 32
> >>> p.flags = re
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: readonly attribute
> >>> p.newattr = re
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 're.Pattern' object has no attribute 'newattr'
>
> I just don't see a way to trick it into being part of a cycle.
>
> Not denying that safe is better than sorry, though.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UO6K3E6MBE6YJJWDSU6VVEUYFS2ONWOT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

[Tim]
> Can you flesh this out for what stumbled into being my running
example? That is, how could a regexp pattern object be part of a
cycle?

Found the problem that we saw regarding a cycle involving the type. That
comes from this comment:

https://github.com/python/cpython/pull/23811#issuecomment-747788766

On Thu, 27 May 2021 at 20:24, Pablo Galindo Salgado 
wrote:

> > Can you flesh this out for what stumbled into being my running
> example? That is, how could a regexp pattern object be part of a
> cycle?
>
> Let me try to remember when we saw this problem in the past, but
> on first sigh, it seems that indeed that cannot happen in the regular case.
>
> > And, in general, I can't add attributes to p, or change their bindings:
>
> That's after the changes to add a new Py_TPFLAGS_IMMUTABLETYPE flag,
> which predates the
> creation of the issue we are discussing. But in general, new heap types
> are not immutable by
> default (check https://bugs.python.org/issue43908).
> For instance, in python3.8:
>
> >>> array.array.x = 4
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: can't set attributes of built-in/extension type 'array.array'
>
> but in python 3.10.0a7 (before Py_TPFLAGS_IMMUTABLETYPE):
>
> Python 3.10.0a7 (tags/v3.10.0a7:53e55290cf, May 27 2021, 20:20:26) [Clang
> 12.0.0 (clang-1200.0.32.29)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import array
> >>> instance = array.array("f")
> >>> type = array.array
> >>> type.instance = instance
>
> On Thu, 27 May 2021 at 20:15, Tim Peters  wrote:
>
>> [Tim]
>> >> And if a type pointer is the only thing being visited, then there's no
>> point
>> >> unless the object can itself be reachable from the type object.
>>
>> {Pablo]
>> > But that could happen easily for heap types as they are mutable by
>> > default. For instance, you set the instance in a global:
>> >
>> > type -> module -> globals -> instance -> type
>>
>> Sorry, but this is apparently a rat's nest and that's too sketchy for me
>> ;-)
>>
>> Can you flesh this out for what stumbled into being my running
>> example? That is, how could a regexp pattern object be part of a
>> cycle?
>>
>> >>> import re
>> >>> p = re.compile("ab*c")
>> >>> type(p)
>> 
>> >>> type(p).__module__
>> 're'
>> >>> type(type(p).__module__)
>> 
>>
>> That is, its __module__ attribute is a string, not a module object.
>>
>> And, in general, I can't add attributes to p, or change their bindings:
>>
>> >>> p.flags
>> 32
>> >>> p.flags = re
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> AttributeError: readonly attribute
>> >>> p.newattr = re
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> AttributeError: 're.Pattern' object has no attribute 'newattr'
>>
>> I just don't see a way to trick it into being part of a cycle.
>>
>> Not denying that safe is better than sorry, though.
>>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/4JNQCNUAHT7IJSOM3ILR4XFA3R7H5Z2T/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

> Can you flesh this out for what stumbled into being my running
example? That is, how could a regexp pattern object be part of a
cycle?

Let me try to remember when we saw this problem in the past, but
on first sigh, it seems that indeed that cannot happen in the regular case.

> And, in general, I can't add attributes to p, or change their bindings:

That's after the changes to add a new Py_TPFLAGS_IMMUTABLETYPE flag, which
predates the
creation of the issue we are discussing. But in general, new heap types are
not immutable by
default (check https://bugs.python.org/issue43908).
For instance, in python3.8:

>>> array.array.x = 4
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't set attributes of built-in/extension type 'array.array'

but in python 3.10.0a7 (before Py_TPFLAGS_IMMUTABLETYPE):

Python 3.10.0a7 (tags/v3.10.0a7:53e55290cf, May 27 2021, 20:20:26) [Clang
12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import array
>>> instance = array.array("f")
>>> type = array.array
>>> type.instance = instance

On Thu, 27 May 2021 at 20:15, Tim Peters  wrote:

> [Tim]
> >> And if a type pointer is the only thing being visited, then there's no
> point
> >> unless the object can itself be reachable from the type object.
>
> {Pablo]
> > But that could happen easily for heap types as they are mutable by
> > default. For instance, you set the instance in a global:
> >
> > type -> module -> globals -> instance -> type
>
> Sorry, but this is apparently a rat's nest and that's too sketchy for me
> ;-)
>
> Can you flesh this out for what stumbled into being my running
> example? That is, how could a regexp pattern object be part of a
> cycle?
>
> >>> import re
> >>> p = re.compile("ab*c")
> >>> type(p)
> 
> >>> type(p).__module__
> 're'
> >>> type(type(p).__module__)
> 
>
> That is, its __module__ attribute is a string, not a module object.
>
> And, in general, I can't add attributes to p, or change their bindings:
>
> >>> p.flags
> 32
> >>> p.flags = re
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: readonly attribute
> >>> p.newattr = re
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 're.Pattern' object has no attribute 'newattr'
>
> I just don't see a way to trick it into being part of a cycle.
>
> Not denying that safe is better than sorry, though.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YQAJ2R4LJWGUSZSEUYVSRYM4CGI5XGF7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

Sorry, the last link should have been:

https://bugs.python.org/issue43908


On Thu, 27 May 2021 at 19:41, Pablo Galindo Salgado 
wrote:

> > Modules dicts are cleared during interpreter shutdown to break
> such cycles.
>
> That is precisely what's not working because of the cycles, check the
> first message in the issue:
>
> https://bugs.python.org/msg385297
>
> > Also: Why are types mutable ? AFAIK, they are only meant to be
> mutable at C level and then only until they are fully initialized
> (PyType_Ready() called).
>
> Check https://bugs.python.org/issue43916
>
>
>
> On Thu, 27 May 2021 at 19:38, Marc-Andre Lemburg  wrote:
>
>> On 27.05.2021 20:20, Pablo Galindo Salgado wrote:
>> >> And if a type pointer is the only thing being visited, then there's
>> > no point unless the object can itself be reachable from the type object.
>> >
>> > But that could happen easily for heap types as they are mutable by
>> default. For
>> > instance, you set the instance in a global:
>> >
>> > type -> module -> globals -> instance -> type
>>
>> Modules dicts are cleared during interpreter shutdown to break
>> such cycles. You would not really want to use GC to clear
>> type objects: if you GC the type object before the instance,
>> this would create really difficult to handle situations :-)
>>
>> Also: Why are types mutable ? AFAIK, they are only meant to be
>> mutable at C level and then only until they are fully initialized
>> (PyType_Ready() called).
>>
>> > On Thu, 27 May 2021, 19:07 Tim Peters, > > <mailto:tim.pet...@gmail.com>> wrote:
>> >
>> > [Tim Peters mailto:tim.pet...@gmail.com>>]
>> > > ...
>> > > This is, I believe, akin to what Marc-Andre is bringing up:  if X
>> > > can't be reached _from_ X's type object, there's no need for X's
>> > > tp_traverse to visit X's type object.  It _can_ be visited, but it
>> > > would be a waste of time.
>> >
>> > Ya, I need to retract that :-)  If X's type object is in a cycle not
>> > directly containing X, and X is in a cycle not directly containing
>> its
>> > type object, and both cycles are dead, then X's tp_traverse must
>> visit
>> > X's type object for cyclic gc to deduce that the cycle directly
>> > containing the type object _is_ dead.
>> >
>> > Else only the cycle containing X will be reclaimed, and the cycle
>> > containing the type object will have to wait for another gc run.
>> >
>> > But that doesn't apply to some of the patches we're seeing. We're
>> > seeing visits to things that can't possibly be parts of cycles:
>> >
>> > +static int
>> > +pattern_traverse(PatternObject *self, visitproc visit, void *arg)
>> > +{
>> > +Py_VISIT(Py_TYPE(self));
>> > +Py_VISIT(self->groupindex);
>> > +Py_VISIT(self->indexgroup);
>> > +Py_VISIT(self->pattern);
>> > +return 0;
>> > +}
>> > +
>> >
>> > For example, self->pattern there is a string.  For that matter, it's
>> > hard to conceive of how a regexp pattern object could possibly be a
>> > direct member of any cycle.
>> >
>> > And if a type pointer is the only thing being visited, then there's
>> no
>> > point unless the object can itself be reachable from the type
>> object.
>> >
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Experts (#1, May 27 2021)
>> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
>> >>> Python Product Development ...https://consulting.egenix.com/
>> 
>>
>> ::: We implement business ideas - efficiently in both time and costs :::
>>
>>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>Registered at Amtsgericht Duesseldorf: HRB 46611
>>https://www.egenix.com/company/contact/
>>  https://www.malemburg.com/
>>
>>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UBNKAASDQNKRHUR7FUT3AFYZ7ZCH5P6G/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

> Modules dicts are cleared during interpreter shutdown to break
such cycles.

That is precisely what's not working because of the cycles, check the first
message in the issue:

https://bugs.python.org/msg385297

> Also: Why are types mutable ? AFAIK, they are only meant to be
mutable at C level and then only until they are fully initialized
(PyType_Ready() called).

Check https://bugs.python.org/issue43916



On Thu, 27 May 2021 at 19:38, Marc-Andre Lemburg  wrote:

> On 27.05.2021 20:20, Pablo Galindo Salgado wrote:
> >> And if a type pointer is the only thing being visited, then there's
> > no point unless the object can itself be reachable from the type object.
> >
> > But that could happen easily for heap types as they are mutable by
> default. For
> > instance, you set the instance in a global:
> >
> > type -> module -> globals -> instance -> type
>
> Modules dicts are cleared during interpreter shutdown to break
> such cycles. You would not really want to use GC to clear
> type objects: if you GC the type object before the instance,
> this would create really difficult to handle situations :-)
>
> Also: Why are types mutable ? AFAIK, they are only meant to be
> mutable at C level and then only until they are fully initialized
> (PyType_Ready() called).
>
> > On Thu, 27 May 2021, 19:07 Tim Peters,  > <mailto:tim.pet...@gmail.com>> wrote:
> >
> > [Tim Peters mailto:tim.pet...@gmail.com>>]
> > > ...
> > > This is, I believe, akin to what Marc-Andre is bringing up:  if X
> > > can't be reached _from_ X's type object, there's no need for X's
> > > tp_traverse to visit X's type object.  It _can_ be visited, but it
> > > would be a waste of time.
> >
> > Ya, I need to retract that :-)  If X's type object is in a cycle not
> > directly containing X, and X is in a cycle not directly containing
> its
> > type object, and both cycles are dead, then X's tp_traverse must
> visit
> > X's type object for cyclic gc to deduce that the cycle directly
> > containing the type object _is_ dead.
> >
> > Else only the cycle containing X will be reclaimed, and the cycle
> > containing the type object will have to wait for another gc run.
> >
> > But that doesn't apply to some of the patches we're seeing. We're
> > seeing visits to things that can't possibly be parts of cycles:
> >
> > +static int
> > +pattern_traverse(PatternObject *self, visitproc visit, void *arg)
> > +{
> > +Py_VISIT(Py_TYPE(self));
> > +Py_VISIT(self->groupindex);
> > +Py_VISIT(self->indexgroup);
> > +Py_VISIT(self->pattern);
> > +return 0;
> > +}
> > +
> >
> > For example, self->pattern there is a string.  For that matter, it's
> > hard to conceive of how a regexp pattern object could possibly be a
> > direct member of any cycle.
> >
> > And if a type pointer is the only thing being visited, then there's
> no
> > point unless the object can itself be reachable from the type object.
> >
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 27 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YDE6JKMGXKQU7WKMJFHUDRAMY7K3C5V7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

> "Why?" is baffling to me: how could they possibly participate in a
cycle?

If the type object is a heap type (by default mutable), someone could just
add a reference directly to it that makes it being in a cycle with the
instance.

Even if that's not the case, IIRC, as the type refers to the module and the
module to the globals, is enough to place an instance of the type in
something reachable from the globals of the same module where the type
object lives to get a cycle involving the type object and the instance.

On Thu, 27 May 2021, 19:27 Tim Peters,  wrote:

> [Tim]
> >> But I think "waste of time" is the worst of it. Participating in
> >> cyclic gc does nothing to delay refcounting from recycling objects
> >> ASAP.  gc only reclaims objects that are reachable only from dead
> >> cycles; everything else in CPython is reclaimed the instant its
> >> refcount falls to 0, and that's so regardless of whether it
> >> participates in cyclic gc.
>
> [Marc-Andre Lemburg]
> > Oh, thanks for the explanation. I was under the impression that
> > GC-aware objects are added to a GC pool for processing at the
> > next GC run.
>
> At creation, they're added to "the youngest GC generation", which is a
> doubly-linked list. It's doubly-linked precisely so (among other
> things ;-) ) they can be removed from the youngest generation in O(1)
> time if refcounting destroys them before the next GC run. GC only
> looks at the objects still in the doubly-linked list when it runs. The
> only effect it has on refcounting is to increase the time it takes
> refcounting to do reclamation (refcounting has to adjust the
> double-linked list pointers, to reflect that the object no longer
> exists).
>
> > If that's not the case in general -- only if they
> > are part of dead cycles -- then it's merely wasting time on
> > traversing known dead ends... and developer time for adding the
> > unnecessary logic ;-)
>
> And some conceptual confusion. For example, I noted in a later message
> that we've apparently added a tp_traverse to regexp pattern objects.
> "Why?" is baffling to me: how could they possibly participate in a
> cycle? My best guess is that there's no need for them to participate
> in cyclic gc at all, despite that - sure - they have a type pointer.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/MEAK2OGPAERT62Y6LF2UXJ4YLRSLDIEJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

> So all those instances have an increase in memory footprint
compared to Python 3.7 ?

I am afraid that's the case. This is one of the costs of making types not
being heap types.

On Thu, 27 May 2021, 19:04 Marc-Andre Lemburg,  wrote:

> On 27.05.2021 19:40, Tim Peters wrote:
> > [Pablo Galindo Salgado ]
> >> Hi Marc,
> >>
> >> Yes, check out this from the 3.9 what's new document:
> >>
> >> https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
> >>
> >> Instances of heap-allocated types (such as those created with
> PyType_FromSpec()
> >> and similar APIs) hold a reference to their type object since Python
> 3.8.
> >> ...
>
> Thanks for these details. I wasn't aware of that change.
>
> So all those instances have an increase in memory footprint
> compared to Python 3.7 ?
>
> > I think Marc-Andre's question is more subtle than that:
> >
> > [Marc-Andre Lemburg, ]
> >>> Hi Pablo,
> >>>
> >>> could you or Erlend please explain why types which don't reference
> >>> any other objects need to participate in GC for deallocation ?
> > ...
> >>> AFAIK (but could be wrong, of course), the type object itself
> >>> does not reference any other objects related to the object
> >>> that is being GCed.
> >
> > To make that more formal, if there's a chain of pointers from an
> > object X that reaches X again (X is a direct member of a cycle), then
> > for cyclic gc to work X's tp_traverse must visit all directly
> > contained objects that could be the second object in a direct cycle
> > reaching X again.
> >
> > But, for example, if X contains a tuple of integers, there's no need
> > for X's tp_traverse to visit that tuple. It's impossible to reach X
> > from the tuple. Cyclic gc cares only about cycles; chasing non-cyclic
> > dead ends doesn't accomplish anything beyond burning processor cycles.
> >
> > This is, I believe, akin to what Marc-Andre is bringing up:  if X
> > can't be reached _from_ X's type object, there's no need for X's
> > tp_traverse to visit X's type object.  It _can_ be visited, but it
> > would be a waste of time.
>
> Indeed, that's what I was after. GC is really only needed for
> objects which can potentially participate in cycles which need
> to be reclaimed. As I understand the logic (even with the objects
> referencing the constant type objects on the heap), many of the
> objects which are now made GC traversal aware don't really have
> a need for it -- their traversal only finds type objects, no
> other objects.
>
> >>> ...
> >>> By having (nearly) all stdlib types participate in GC, even ones
> >>> which don't reference other objects and cannot be parts of reference
> >>> circles, instead of immediately deleting them, we will keep those
> >>> objects alive for much longer than necessary, potentially causing a
> >>> resource overhead regression.
> >
> > But I think "waste of time" is the worst of it. Participating in
> > cyclic gc does nothing to delay refcounting from recycling objects
> > ASAP.  gc only reclaims objects that are reachable only from dead
> > cycles; everything else in CPython is reclaimed the instant its
> > refcount falls to 0, and that's so regardless of whether it
> > participates in cyclic gc.
>
> Oh, thanks for the explanation. I was under the impression that
> GC-aware objects are added to a GC pool for processing at the
> next GC run. If that's not the case in general -- only if they
> are part of dead cycles -- then it's merely wasting time on
> traversing known dead ends... and developer time for adding the
> unnecessary logic ;-)
>
> Perhaps this provides an easy way to unblock the release :-)
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 27 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/Q7AT6AY3CUT5SUKF6TSWP5VK5NVTKBNR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

> And if a type pointer is the only thing being visited, then there's no
 point unless the object can itself be reachable from the type object.

But that could happen easily for heap types as they are mutable by default.
For instance, you set the instance in a global:

type -> module -> globals -> instance -> type

On Thu, 27 May 2021, 19:07 Tim Peters,  wrote:

> [Tim Peters ]
> > ...
> > This is, I believe, akin to what Marc-Andre is bringing up:  if X
> > can't be reached _from_ X's type object, there's no need for X's
> > tp_traverse to visit X's type object.  It _can_ be visited, but it
> > would be a waste of time.
>
> Ya, I need to retract that :-)  If X's type object is in a cycle not
> directly containing X, and X is in a cycle not directly containing its
> type object, and both cycles are dead, then X's tp_traverse must visit
> X's type object for cyclic gc to deduce that the cycle directly
> containing the type object _is_ dead.
>
> Else only the cycle containing X will be reclaimed, and the cycle
> containing the type object will have to wait for another gc run.
>
> But that doesn't apply to some of the patches we're seeing. We're
> seeing visits to things that can't possibly be parts of cycles:
>
> +static int
> +pattern_traverse(PatternObject *self, visitproc visit, void *arg)
> +{
> +Py_VISIT(Py_TYPE(self));
> +Py_VISIT(self->groupindex);
> +Py_VISIT(self->indexgroup);
> +Py_VISIT(self->pattern);
> +return 0;
> +}
> +
>
> For example, self->pattern there is a string.  For that matter, it's
> hard to conceive of how a regexp pattern object could possibly be a
> direct member of any cycle.
>
> And if a type pointer is the only thing being visited, then there's no
> point unless the object can itself be reachable from the type object.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TO4SD5USMVM5JJ636Q7VGA4PBZ5EJA42/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-27 Thread Pablo Galindo Salgado

Hi Marc,

Yes, check out this from the 3.9 what's new document:

https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api

Instances of heap-allocated types (such as those created with
PyType_FromSpec() and similar APIs) hold a reference to their type object
since Python 3.8. As indicated in the “Changes in the C API” of Python 3.8,
for the vast majority of cases, there should be no side effect but for
types that have a custom tp_traverse function, ensure that all custom
tp_traverse functions of heap-allocated types visit the object’s type.

Example:

int
foo_traverse(foo_struct *self, visitproc visit, void *arg) {
// Rest of the traverse function
#if PY_VERSION_HEX >= 0x0309
// This was not needed before Python 3.9 (Python issue 35810 and 40217)
Py_VISIT(Py_TYPE(self));
#endif
}
If your traverse function delegates to tp_traverse of its base class (or
another type), ensure that Py_TYPE(self) is visited only once. Note that
only heap types are expected to visit the type in tp_traverse.

For example, if your tp_traverse function includes:

base->tp_traverse(self, visit, arg)
then add:

#if PY_VERSION_HEX >= 0x0309
// This was not needed before Python 3.9 (Python issue 35810 and 40217)
if (base->tp_flags & Py_TPFLAGS_HEAPTYPE) {
// a heap type's tp_traverse already visited Py_TYPE(self)
} else {
Py_VISIT(Py_TYPE(self));
}
#else
(See bpo-35810 and bpo-40217 for more information.)

Regards from sunny London,
Pablo

On Thu, 27 May 2021, 16:36 Marc-Andre Lemburg,  wrote:

> Hi Pablo,
>
> could you or Erlend please explain why types which don't reference
> any other objects need to participate in GC for deallocation ?
>
> Many PRs or checked in patches only do this:
>
> +static int
> +ucd_traverse(PreviousDBVersion *self, visitproc visit, void *arg)
> +{
> +Py_VISIT(Py_TYPE(self));
> +return 0;
> +}
> +
>
> AFAIK (but could be wrong, of course), the type object itself
> does not reference any other objects related to the object
> that is being GCed.
>
> By having (nearly) all stdlib types participate in GC, even ones
> which don't reference other objects and cannot be parts of reference
> circles, instead of immediately deleting them, we will keep those
> objects alive for much longer than necessary, potentially causing a
> resource overhead regression.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 27 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/6EI25PX6FIH6ILWYYJ3AXMZUP5VWQZ4K/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-26 Thread Pablo Galindo Salgado

The friendly reminder is so we don't forget that we are blocked by the
issue. Also, a small and friendly ping the the core devs that made the
changes in the first place that require this fix to get involved in the
issue, as the process is blocked by changes they authored or reviewed and
merged.

Regarding the work itself, Erlend has created a bunch of pull requests that
cover most of it, I am reviewing them as fast as possible but as you said
there is a lot to do so it certainly would welcome more reviews.

On Wed, 26 May 2021, 15:50 Larry Hastings,  wrote:

> On 5/26/21 7:21 AM, Pablo Galindo Salgado wrote:
>
> Hi,
>
> Friendly reminder that the Python3.10 beta 2 is still blocked on:
>
> https://bugs.python.org/issue42972
>
> Thanks for your help,
>
> Regards from stormy London,
> Pablo Galindo Salgado
>
>
> I took a quick look at that issue.  My cursory understanding is that
> there's a gigantic list of work that just needs seasoned CPython core devs
> to power through--specifically, implementing full GC protocol for a long
> list of extension types that (I'm assuming) happen to hold references to
> other objects.  Is this friendly reminder your way of asking for volunteers
> to carve off a chunk and do the work?
>
>
> Cheers,
>
>
> */arry*
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/7WL4BZNILHFQCH4MTDN6LE6KGCSHIKFD/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UN3JKUHZIWPE5RRYQMN3WA5T7RZBLW5V/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-26 Thread Pablo Galindo Salgado

Hi,

Friendly reminder that the Python3.10 beta 2 is still blocked on:

https://bugs.python.org/issue42972

Thanks for your help,

Regards from stormy London,
Pablo Galindo Salgado

On Mon, 24 May 2021 at 23:54, Pablo Galindo Salgado 
wrote:

> Small correction:
>
> https://bugs.python.org/issue40222: "Zero cost" exception handling
>
> and the segfaults on these buildbots:
>
>
> https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio
> https://buildbot.python.org/all/#/builders/543/builds/190
>
> are 3-11 (main branch) only, but they are also quite important to get
> fixed as soon as possible,
> so the buildbot failures don't pile up.
>
> On the other hand, seems that there is a nasty race condition on
> test_asyncio and many of the refleak
> builders for 3.10 hang, rendering them not usefull:
>
> https://buildbot.python.org/all/#/builders/693/builds/21
> https://buildbot.python.org/all/#/builders/677/builds/22
> https://buildbot.python.org/all/#/builders/669/builds/22
> ...
>
> You can access the release dashboard for the buildbots here:
>
> https://buildbot.python.org/all/#/release_status
>
> On Mon, 24 May 2021 at 23:45, Pablo Galindo Salgado 
> wrote:
>
>> Hi,
>>
>> Tomorrow is the scheduled release of Python 3.10 beta 2 but unfortunately
>> we have several release blockers:
>>
>> https://bugs.python.org/issue41282: Deprecate and remove distutils
>> https://bugs.python.org/issue40222: "Zero cost" exception handling
>> https://bugs.python.org/issue42972: [C API] Heap types (PyType_FromSpec)
>> must fully implement the GC protocol
>> https://bugs.python.org/issue44043: 3.10 b1 armhf Bus Error in hashlib
>> test: test_gil
>>
>> We also have the address sanitizer buildbot failing :
>>
>>
>> https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio
>>
>> and some segmentation faults on the fedora stable buildbot:
>>
>> https://buildbot.python.org/all/#/builders/543/builds/190
>>
>> Some of these issues have PRs but some of them have not. Please, if you
>> are involved or you maintain one of the
>> areas involved in these issues, take a look at them and act with one of
>> the following:
>>
>> * Fix the issue making a PR
>> * Review an existing PR and / or merge it
>> * If you intend to mark it as a deferred blocker, please provide a
>> rationale and contact me first by pinging me in the issue.
>>
>> Until these issues are fixed or deferred, the release team will not be
>> able to make a new beta release.
>>
>> Thanks for your help,
>>
>> Regards from stormy London,
>> Pablo Galindo Salgado
>>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/I43AL4Q2PIDNISC7OOJBAGZTPGRB67KR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

2021-05-24 Thread Pablo Galindo Salgado

Small correction:

https://bugs.python.org/issue40222: "Zero cost" exception handling

and the segfaults on these buildbots:

https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio
https://buildbot.python.org/all/#/builders/543/builds/190

are 3-11 (main branch) only, but they are also quite important to get fixed
as soon as possible,
so the buildbot failures don't pile up.

On the other hand, seems that there is a nasty race condition on
test_asyncio and many of the refleak
builders for 3.10 hang, rendering them not usefull:

https://buildbot.python.org/all/#/builders/693/builds/21
https://buildbot.python.org/all/#/builders/677/builds/22
https://buildbot.python.org/all/#/builders/669/builds/22
...

You can access the release dashboard for the buildbots here:

https://buildbot.python.org/all/#/release_status

On Mon, 24 May 2021 at 23:45, Pablo Galindo Salgado 
wrote:

> Hi,
>
> Tomorrow is the scheduled release of Python 3.10 beta 2 but unfortunately
> we have several release blockers:
>
> https://bugs.python.org/issue41282: Deprecate and remove distutils
> https://bugs.python.org/issue40222: "Zero cost" exception handling
> https://bugs.python.org/issue42972: [C API] Heap types (PyType_FromSpec)
> must fully implement the GC protocol
> https://bugs.python.org/issue44043: 3.10 b1 armhf Bus Error in hashlib
> test: test_gil
>
> We also have the address sanitizer buildbot failing :
>
>
> https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio
>
> and some segmentation faults on the fedora stable buildbot:
>
> https://buildbot.python.org/all/#/builders/543/builds/190
>
> Some of these issues have PRs but some of them have not. Please, if you
> are involved or you maintain one of the
> areas involved in these issues, take a look at them and act with one of
> the following:
>
> * Fix the issue making a PR
> * Review an existing PR and / or merge it
> * If you intend to mark it as a deferred blocker, please provide a
> rationale and contact me first by pinging me in the issue.
>
> Until these issues are fixed or deferred, the release team will not be
> able to make a new beta release.
>
> Thanks for your help,
>
> Regards from stormy London,
> Pablo Galindo Salgado
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/GBD57CUUU4K5NMQDTEZXNCX76YISEIGQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] IMPORTANT: Python 3.10b2 release blockers

2021-05-24 Thread Pablo Galindo Salgado

Hi,

Tomorrow is the scheduled release of Python 3.10 beta 2 but unfortunately
we have several release blockers:

https://bugs.python.org/issue41282: Deprecate and remove distutils
https://bugs.python.org/issue40222: "Zero cost" exception handling
https://bugs.python.org/issue42972: [C API] Heap types (PyType_FromSpec)
must fully implement the GC protocol
https://bugs.python.org/issue44043: 3.10 b1 armhf Bus Error in hashlib
test: test_gil

We also have the address sanitizer buildbot failing :

https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio

and some segmentation faults on the fedora stable buildbot:

https://buildbot.python.org/all/#/builders/543/builds/190

Some of these issues have PRs but some of them have not. Please, if you are
involved or you maintain one of the
areas involved in these issues, take a look at them and act with one of the
following:

* Fix the issue making a PR
* Review an existing PR and / or merge it
* If you intend to mark it as a deferred blocker, please provide a
rationale and contact me first by pinging me in the issue.

Until these issues are fixed or deferred, the release team will not be able
to make a new beta release.

Thanks for your help,

Regards from stormy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Irit Katriel to the team!

2021-05-11 Thread Pablo Galindo Salgado

Congratulations, Irit!

On Tue, 11 May 2021 at 06:18, Brett Cannon  wrote:

> EOM
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/RJLSGQW233DBYJWKXGHCXVZUKLMOTYJR/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/E37PVMHFUM2XFHC7NMCBDBYI56HLK3FO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Important: Python3.10 what's new

2021-05-10 Thread Pablo Galindo Salgado

Hi everyone,

Now that we are in the beta period for 3.10 is very important that we make
sure that all
improvements, new APIs and deprecations are reflected in the 3.10 what's
New document.

IMPORTANT!!

If you have worked on:

* Make a PEP that affects Python 3.10.
* A new feature/class/function/argument/option...
* Deprecating something.
* Remove something.
* Improve something important.

Please, make sure is reflected on the What's new document for Python 3.10.
Users normally don't
read the changelog directly and learn about what's available from the
What's New document so
you *absolutely* want your work to be reflected there. *Small* tutorials
and small code samples
and descriptions are a fantastic thing to add as well.

Specially for deprecations and removals, this is our public window to the
world so that learn what's
coming or how to port code to Python 3.10.

Thanks for helping to make Python3.10 a great release.

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/DC37BKDIPECMRHZSXI3RSBTWE3TOKLDZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [Release manager team communication] master blocked until 3.10 beta 1 is released

2021-05-03 Thread Pablo Galindo Salgado

Hi everyone,

Unfortunately, the CI for master is currently quite unstable and he had
some problems that we
have been fixing all weekend and today. We are doing our best to stabilize
the test suite and making
sure that everything is ready to go for the release with no issues, but
this will take some time (also
bear in mind that today is a bank holiday in the UK, so I am doing my best
to get the release ready
in a holiday). Given this and the fact that we need to do a branch rename,
**we have decided to block the master branch** until we can stabilize the
test suite.

In the meantime, if you have some urgent fix or PR that you absolutely need
to get merge before
feature freeze, you can add me as a reviewer to said PR so we can evaluate
the merge.

Thanks for your understanding.

I will update once master is unblocked again.

Regards from cloudy London, Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/AKSCARRZJKKU427Z7DIMYO7MK5RSXOFR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [Release management team communication] 3.10 feature freeze is 1 week away

2021-04-26 Thread Pablo Galindo Salgado

Hi everyone,

This is the last friendly reminder from the release management team that
Python 3.10 feature freeze is a week away (Monday, 3 May 2021).

Some important things to have in mind:

* We have some release blockers that must be resolved before the release is
done:

https://bugs.python.org/issue43908
https://bugs.python.org/issue43933
https://bugs.python.org/issue43916

If you want to help making sure that the release is on time, help us
resolving those blockers. You can also search the issues in
https://bugs.python.org/issue?@template=search&status=1 with the
"release-blocker" priority.

* Please, don't wait until the last moment (Sunday) to merge PRs into
master. This is because if many changes accumulate into a time window and
problems are detected, is much more difficult to locate the problematic
changes among the rest. If there are any problems with your commits, you
also would have the risk of having your changes reverted to unblock the
release without any time window to merge them again before feature freeze.

Please, also be aware of the following:

* No new features or improvements should be merged after the feature
freeze. From the devguide (https://devguide.python.org/devcycle/#beta) :

> After a first beta release is published, no new features are accepted.
Only bug fixes and improvements to documentation and tests can now be
committed.
> This is when core developers should concentrate on the task of fixing
regressions and other new issues filed by users who have downloaded the
alpha and beta releases.
> Being in beta can be viewed much like being in RC but without the extra
overhead of needing commit reviews.

* If your change involves some platform-specific behaviour or has a
non-trivial amount of C code, make sure you run the buildbots
in your Pull Request by using the "test-with-buildbots" label (
https://discuss.python.org/t/now-you-can-test-a-pr-with-the-buildbots-before-merging/2966
).
Alternatively you could check the buildbots post-merge in the buildbot
server:
https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Bstable
This is very important because if problems are detected at the time of the
release, the release management team may have to revert
the changes and therefore those will not be included in Python 3.10.

* The master branch will be renamed to main (check our previous
communication about how this will be done and how you should
proceed
https://mail.python.org/archives/list/python-...@python.org/thread/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
)

If you have any questions or concerns, please contact me as soon as
possible.

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/V7V5JHKZCJVE2GTI5NFEP3PNKOLH35VL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [Release manager team communication] 3.10 feature freeze is 2 weeks away

2021-04-19 Thread Pablo Galindo Salgado

Hi everyone,

This is a friendly reminder from the release manager team that Python 3.10
feature freeze is two weeks away (Monday, 3 May 2021).

Please, be aware of the following:

* No new features or improvements should be merged after feature freeze.
>From the devguide (https://devguide.python.org/devcycle/#beta) :
> After a first beta release is published, no new features are accepted.
Only bug fixes can now be committed. This is when core developers should
> concentrate on the task of fixing regressions and other new issues filed
by users who have downloaded the alpha and beta release

* If your change involves some platform-specific behaviour or has a
non-trivial amount of C code, make sure you run the buildbots
in your Pull Request by using the "test-with-buildbots" label (
https://discuss.python.org/t/now-you-can-test-a-pr-with-the-buildbots-before-merging/2966
).
Alternatively you could check the buildbots post-merge in the buildbot
server:
https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Bstable
This is very important because if problems are detected at the time of the
release, the release management team may have to revert
the changes and therefore those will not be included in Python 3.10.

* The master branch will be renamed to main (check our previous
communication about how this will be done and how you should
proceed:
https://mail.python.org/archives/list/python-...@python.org/thread/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
)

If you have any questions or concerns, please contact me as soon as
possible.

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SIJQE3BZ6ICCGNJWFR4YR65BQBJJZZAZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Ken Jin got the bug triage permission

2021-04-11 Thread Pablo Galindo Salgado

Hi everyone,

I started to mentor Ken Jin (Fidget-Spinner on Github) and I gave him bug
triage permission on bpo (soon on GitHub as well) :

https://github.com/python/core-workflow/issues/396

He got 39 commits merged into master:

https://github.com/python/cpython/commits?author=Fidget-Spinner

In a total of 48 PRs (including manual backports):

https://github.com/python/cpython/pulls?q=is%3Apr+author%3AFidget-Spinner+is%3Amerged+

He has made great progress in learning the CPython workflow, CPython
internals and how to keep things maintainable
and backwards compatible so I decided to give him bug triage permission. I
will continue mentoring him and I will send him
instructions on how to triage bugs and links to the relevant sections of
the devguide. I ask him to ask me before closing bugs
for the first weeks.

Congrats Ken Jin ✨ 🍰 ✨!

Regards from sunny London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/5JQD4Q65TNG7CXXFBRWGRQ4YMY3ZTPAJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

2021-04-06 Thread Pablo Galindo Salgado

> This is one of the several reasons that I don't like using the PR
description as the commit message when using auto-merge :).

I think this is a good motivation to use
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
instead as you can write your own commit message there and schedule the
merge.


On Tue, 6 Apr 2021 at 16:52, Zachary Ware  wrote:

> On Tue, Apr 6, 2021 at 9:36 AM Victor Stinner  wrote:
> > I'm getting more and more email notifications when a commit contains
> > my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By:
> > @vstinner".
>
> Yes, this is a pretty substantial failing of GitHub for popular projects :(
>
> > But the problem is that the "automerge" labels uses
> > "Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement
> > would be to use ""Automerge-Triggered-By: vstinner" syntax instead
> > (avoid the @).
>
> This is already done; see
>
> https://github.com/python/miss-islington/commit/334c817cecf6c5c7f074ec7dbbad89d491b42f1a
> (we now use `GH:vstinner` to keep it clear that it's a GitHub handle
> without triggering GitHub's automatic linking/mentioning).
>
> > Some developers put my handle in a commit message since it becomes the
> > PR descriptor and sends ping me by email. But then my handle lands
> > into the merged commit message, like:
> > ...
> > I'm not asking you to stop mentioning me. I'm just asking for help how
> > to filter these notifications?
>
> This is one of the several reasons that I don't like using the PR
> description as the commit message when using auto-merge :).  I still
> think we ought to require a new comment with a special marker to
> contain the commit message.  I haven't found time or motivation to
> actually try to make this change, though.
>
> That change wouldn't help with existing messy commits, though, and
> those keep popping up when someone does something weird with their
> fork, like rebasing one stable branch on another.  I'm afraid I don't
> have a good solution for that that doesn't risk masking the messages
> you might actually want to see :(
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/WDPQ5I6NBT6IRDKA4WQPVEWHQIUTPHJ7/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/ZDKEB6CORVOJ4NWUFQDAXWKSV7VSO5LS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] The last Python 3.10 alpha (3.10.0a7) is available - Prepare for beta freeze

2021-04-06 Thread Pablo Galindo Salgado

Br. do you feel that? That's the chill of *beta freeze* coming
closer. Meanwhile, your friendly CPython release team doesn’t
rest even on holidays and we have prepared a shiny new release for you:
Python 3.10.0a7.

Dear fellow core developer:
This alpha is the last release before feature freeze (2021-05-03), so make
sure that all new features and PEPs are landed in the master branch before
we
release the first beta. Please, be specially mindfully to check the CI and
the buildbots, maybe even using the test-with-buildbots label in GitHub
before
merging so the release team don’t need to fix a bunch of reference leaks or
platform-specific problems on the first beta release.

*Go get the new alpha here:*
https://www.python.org/downloads/release/python-3100a7/

*Python 3.10.0a7*Release Date: April 5, 2021

This is an early developer preview of Python 3.10

*Major new features of the 3.10 series, compared to 3.9*

Python 3.10 is still in development. This release, 3.10.0a7 is the last 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 (2021-05-03) and, if necessary, may be modified or
deleted up until the release candidate phase (2021-10-04). 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.10 are still being planned and written.
Among the new major new features and changes so far:

PEP 623 – Deprecate and prepare for the removal of the wstr member in
PyUnicodeObject.
PEP 604 – Allow writing union types as X | Y
PEP 612 – Parameter Specification Variables
PEP 626 – Precise line numbers for debugging and other tools.
bpo-38605: from __future__ import annotations (PEP 563) is now the default.
PEP 618 – Add Optional Length-Checking To zip.
bpo-12782: Parenthesized context managers are now officially allowed.
PEP 632 – Deprecate distutils module.
PEP 613 – Explicit Type Aliases
PEP 634 – Structural Pattern Matching: Specification
PEP 635 – Structural Pattern Matching: Motivation and Rationale
PEP 636 – Structural Pattern Matching: Tutorial
PEP 644 – Require OpenSSL 1.1.1 or newer
PEP 624 – Remove Py_UNICODE encoder APIs
PEP 597 – Add optional EncodingWarning
(Hey, fellow core developer, if a feature you find important is missing
from this list, let Pablo know.)
The next pre-release of Python 3.10 will be 3.10.0b1 ( the first beta
release and feature freeze ), currently scheduled for Monday, 2021-05-03.

*And now for something completely different*

In physics, the twin paradox is a thought experiment in special relativity
involving identical twins, one of whom makes a journey into space in a
high-speed rocket and returns home to find that the twin who remained on
Earth has aged more. This result appears puzzling because each twin sees
the other twin as moving, and so, as a consequence of an incorrect and
naive application of time dilation and the principle of relativity, each
should paradoxically find the other to have aged less. However, this
scenario can be resolved by realising that the travelling twin is
undergoing acceleration, which makes him a non-inertial observer. In both
views, there is no symmetry between the spacetime paths of the twins.
Therefore, the twin paradox is not a paradox in the sense of a logical
contradiction.

Your friendly release team,
Pablo Galindo Salgado @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/G2J3SBJ4EOW6MQZZJQNTXKHRWTAVBMKP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 652 Accepted -- Maintaining the Stable ABI

2021-04-05 Thread Pablo Galindo Salgado

Hi Petr,

Thank you for submitting PEP 652 (Maintaining the Stable ABI). After
evaluating
the situation and discussing the PEP, the Steering Council is happy with
the PEP
and hereby accepts it. The Steering council thinks that this is a great
step forward
in order to have a clear definition of what goes into the Stable ABI and
what guarantees
the Python core team offers regarding the stable ABI while offering at the
same time a
plan to improve the maintenance and stability of the stable ABI.

We would also like to see some improvements in the official documentation
(not only on the
devguide) regarding this topic and what guarantees do we offer (currently
we only have a small
section about this in https://docs.python.org/3/c-api/stable.html but there
is a lot of information
and clarifications in the PEP that we would like to be also in the
documentation).

Congratulations, Petr!

With thanks from the whole Python Steering Council,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/IN4XMFLQJ6D6V67EXU27GV3QWSEHHNNH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer

2021-03-30 Thread Pablo Galindo Salgado

Hi Christian,

Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating
the situation and discussing the PEP, the Steering Council is happy with
the PEP,
and hereby accepts it. The SC is of the opinion that this change will make
it considerable
easier to maintain the extension modules that depend on OpenSSL while
allowing us
to leverage the new APIs and improvements in the future. As indicated in
the PEP,
OpenSSL 1.1.1 is the default variant and version of OpenSSL on almost all
supported
platforms and distributions almost all known Major CI providers provide
images with
OpenSSL 1.1.1, so we believe this has the right balance to improve the
situation without
causing major impact or breakage.

Nevertheless, the Steering Council would like to see this change reflected
properly in the
documentation, What's New (linking against the new instructions here:
https://docs.python.org/3.10/using/unix.html#custom-openssl) and release
manager notices
so this is properly communicated to our users.

The Steering Council also thanks Christian for his patience explaining
different aspects
of the PEP, including in the PEP some extra requested information and for
considering
the concerts raised.

Congratulations, Christian!

With thanks from the whole Python Steering Council,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/INLCO2EZVQW7R7J2OL6HWVLVU3TQRAZV/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [Python-Dev] Re: [Release management] schedule for renaming the default branch

2021-03-11 Thread Pablo Galindo Salgado

> I have above 200 feature branches in my local > repository. Will renaming
> the master branch cause any problems?

It should not be any problem at all. If you have some open PRs from some of
those branches, they will be automatically retargeted to the new branch
name in GitHub automatically.

On Thu, 11 Mar 2021, 07:37 Serhiy Storchaka,  wrote:

> 10.03.21 16:06, Pablo Galindo Salgado пише:
> > # What you need to do?
> >
> > You just need to update your local clone after the branch name changes.
> > From the local clone of the repository on a computer,
> > run the following commands to update the name of the default branch.
> >
> > $ git branch -m master main
> > $ git fetch origin
> > $ git branch -u origin/main main
> >
> > Apart from that, you should update any local script or command that uses
> > the name "master" to use the name "main".
>
> I have above 200 feature branches in my local repository. Will renaming
> the master branch cause any problems?
>
> ___
> Python-Dev mailing list -- python-...@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-...@python.org/message/G2LLBPJMIBD2DOA7AVTYYA77PGLGYLUE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/6IVJZTCQ47F6MDBIF3UNY2DACHRBXHJO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [Python-Dev] Re: [Release management] schedule for renaming the default branch

2021-03-10 Thread Pablo Galindo Salgado

I am answering this as a member of the release management team, not as an
official response from the SC.

> and understand who the identified impacted parties are

All developers that have clones of the repository and any party maintaining
any script that interacts with the default CPython branch.

> and what the plan is to notify them

These messages on python-dev and python-comitters + messages in the
official release announcement and notes.

> and help them update within this timescale

For the repositories, execute the commands listed in the previous message.
For scrips and other references to the main branch,
they need to do the change themselves but in most cases is a simple rename
master->main.

> Has this analysis been published anywhere

No. It has been discussed by the Steering Council as you can see in the
February update:
https://github.com/python/steering-council/blob/main/updates/2021-02-steering-council-update.md



On Wed, 10 Mar 2021 at 14:21, Stestagg  wrote:

> Hi
>
> I would be great to read the impact analysis for this change, and
> understand who the identified impacted parties are, and what the plan is to
> notify them and help them update within this timescale.
>
> Has this analysis been published anywhere? I know there are lots of places
> where discussions/documentation happens
>
> Thanks
>
> Steve
>
>
>
> On Wed, Mar 10, 2021 at 2:10 PM Pablo Galindo Salgado 
> wrote:
>
>> Hi,
>>
>> I am writing on behalf of the Python Release Management team. The
>> Steering Council has requested the RM team to schedule
>> and perform the necessary changes to rename the default branch from
>> master to main.
>>
>> # The changes
>>
>> What follows is the technical description of the changes and the
>> timeline. In order to keep this thread focused on this particular
>> aspect, if you wish to discuss anything related to the change itself,
>> please, open a new email thread or reuse an existing one.
>>
>>- The change will be executed ***when beta 1 is released***, as the
>>beta 1 release requires some branching engineering already
>>to create the 3.10 branch and point 3.11 to the new one as well as
>>changing CI, buildbots...etc **
>> *This is scheduled for Monday, 2021-05-03**.*
>>- The CI will be adapted to work with the new "main" branch.
>>- The buildbots will be adapted to work with the new "main" branch.
>>- Branch protection rules will be adapted.
>>- The different bots will be adapted by the respective bot maintainer
>>teams.
>>- All the URLs that point to master in the README and other places
>>will be adapted to point to main instead (notice this is
>>not strictly necessary because GitHub redirects automatically).
>>
>> Notice that the renaming will automatically:
>>
>>
>>- Re-target any open pull requests
>>- Update any draft releases based on the branch
>>- Move any branch protection rules that explicitly reference the old
>>name
>>- Show a notice to repository contributors, maintainers, and admins
>>on the repository homepage with instructions to update local copies of the
>>repository
>>- Show a notice to contributors who git push to the old branch
>>- Redirect web requests for the old branch name to the new branch name
>>- Return a "Moved Permanently" response in API requests for the old
>>branch name
>>
>> Check this <https://github.com/github/renaming> for more information.
>>
>> # What you need to do?
>>
>> You just need to update your local clone after the branch name changes.
>> From the local clone of the repository on a computer,
>> run the following commands to update the name of the default branch.
>>
>> $ git branch -m master main
>> $ git fetch origin
>> $ git branch -u origin/main main
>>
>> Apart from that, you should update any local script or command that uses
>> the name "master" to use the name "main".
>>
>> Regards from windy London,
>> Pablo Galindo Salgado
>> ___
>> Python-Dev mailing list -- python-...@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-...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing li

[python-committers] [Release management] schedule for renaming the default branch

2021-03-10 Thread Pablo Galindo Salgado

Hi,

I am writing on behalf of the Python Release Management team. The Steering
Council has requested the RM team to schedule
and perform the necessary changes to rename the default branch from master
to main.

# The changes

What follows is the technical description of the changes and the timeline.
In order to keep this thread focused on this particular
aspect, if you wish to discuss anything related to the change itself,
please, open a new email thread or reuse an existing one.

   - The change will be executed ***when beta 1 is released***, as the beta
   1 release requires some branching engineering already
   to create the 3.10 branch and point 3.11 to the new one as well as
   changing CI, buildbots...etc **
*This is scheduled for Monday, 2021-05-03**.*
   - The CI will be adapted to work with the new "main" branch.
   - The buildbots will be adapted to work with the new "main" branch.
   - Branch protection rules will be adapted.
   - The different bots will be adapted by the respective bot maintainer
   teams.
   - All the URLs that point to master in the README and other places will
   be adapted to point to main instead (notice this is
   not strictly necessary because GitHub redirects automatically).

Notice that the renaming will automatically:


   - Re-target any open pull requests
   - Update any draft releases based on the branch
   - Move any branch protection rules that explicitly reference the old name
   - Show a notice to repository contributors, maintainers, and admins on
   the repository homepage with instructions to update local copies of the
   repository
   - Show a notice to contributors who git push to the old branch
   - Redirect web requests for the old branch name to the new branch name
   - Return a "Moved Permanently" response in API requests for the old
   branch name

Check this <https://github.com/github/renaming> for more information.

# What you need to do?

You just need to update your local clone after the branch name changes.
>From the local clone of the repository on a computer,
run the following commands to update the name of the default branch.

$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main

Apart from that, you should update any local script or command that uses
the name "master" to use the name "main".

Regards from windy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Python 3.10.0a6 is available, now with 100% more pattern matching

2021-03-02 Thread Pablo Galindo Salgado

Remember us? It's your friendly CPython release team and we have something
we think you may like: The new alpha release of Python 3.10 is here, now
with 100% more pattern matching. If I were you, I would download it and
start playing with it. Extra points if you report us any bugs you find
along the way! Are you confused about all this pattern matching business?
Fear not, this release also includes some fantastic documentation and some
shiny new "What's new" entries.

Check them here and tell us how we can improve it:

What's new: https://docs.python.org/3.10/whatsnew/3.10.html
Tutorial:
https://docs.python.org/3.10/tutorial/controlflow.html#match-statements

Go get the new alpha here:

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

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

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

Python 3.10 is still in development.  This release, 3.10.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 (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04).  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.10 are still being planned and written.
Among the new major
new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from
Unicode
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now
the default.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial


* (Hey, **fellow core developer,** if a feature you find important
is missing from this list, [let Pablo know](mailto:pablog...@python.org
).)

The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release),
currently scheduled for Monday, 2021-04-05.

# More resources

* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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
Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after
Albert Einstein and Nathan Rosen), are connections between areas of space
that can be modelled as vacuum solutions to the Einstein field equations,
and that are now understood to be intrinsic parts of the maximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that the spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
the spacetime).

Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).

Regards from rainy London,

Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/LZV62UZIHZGM3Y33ZQC2H3NPUZBOOGV2/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0a6 is available, now with 100% more pattern matching

2021-03-02 Thread Pablo Galindo Salgado

Remember us? It's your friendly CPython release team and we have something
we think you may like: The new alpha release of Python 3.10 is here, now
with 100% more pattern matching. If I were you, I would download it and
start playing with it. Extra points if you report us any bugs you find
along the way! Are you confused about all this pattern matching business?
Fear not, this release also includes some fantastic documentation and some
shiny new "What's new" entries.

Check them here and tell us how we can improve it:

What's new: https://docs.python.org/3.10/whatsnew/3.10.html
Tutorial:
https://docs.python.org/3.10/tutorial/controlflow.html#match-statements

Go get the new alpha here:

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


*Note: The alpha was officially released yesterday, but my email client
failed to deliver this email to the mailing lists so I am reposting it.*
**This is an early developer preview of Python 3.10**

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

Python 3.10 is still in development.  This release, 3.10.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 (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04).  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.10 are still being planned and written.
Among the new major
new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from
Unicode
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now
the default.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial

* (Hey, **fellow core developer,** if a feature you find important
is missing from this list, [let Pablo know](mailto:pablog...@python.org
).)

The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release),
currently scheduled for Monday, 2021-04-05.

# More resources

* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 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
Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after
Albert Einstein and Nathan Rosen), are connections between areas of space
that can be modelled as vacuum solutions to the Einstein field equations,
and that are now understood to be intrinsic parts of the maximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that the spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
the spacetime).

Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).

Regards from rainy London,

Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/VGZDQ5TFMSWEQZS6HNDLDJQ7GAASGUUB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Python 3.10.0a5 is now available

2021-02-03 Thread Pablo Galindo Salgado

Well, this one took a bit more time due to some surprise last time
reference leaks and release blockers to fix, but now Python 3.10.0a5 it’s
here. Will this be the first release announcement of the 3.10 series
without copy-paste typos? Go get it here:

https://www.python.org/downloads/release/python-3100a5/

*Major new features of the 3.10 series, compared to 3.9*

Python 3.10 is still in development. This release, 3.10.0a5 is the fifth 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 (2021-05-03) and, if necessary, may be modified or
deleted up until the release candidate phase (2021-10-04). 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.10 are still being planned and written.
Among the new major new features and changes so far:

- PEP 623 <https://www.python.org/dev/peps/pep-0623/> – Remove wstr from
Unicode
- PEP 604 <https://www.python.org/dev/peps/pep-0604/> – Allow writing
union types as X | Y
- PEP 612 <https://www.python.org/dev/peps/pep-0612/> – Parameter
Specification Variables
- PEP 626 <https://www.python.org/dev/peps/pep-0626/> – Precise line
numbers for debugging and other tools.
- bpo-38605 <https://bugs.python.org/issue38605>: from __future__ import
annotations (PEP 563 <https://www.python.org/dev/peps/pep-0563/>) is now
the default.
- PEP 618 <https://www.python.org/dev/peps/pep-0618/>– Add Optional
Length-Checking To zip.
- bpo-12782 <https://bugs.python.org/issue12782>: Parenthesized context
managers are now officially allowed.
- (Hey, fellow core developer, if a feature you find important is
missing from this list, let Pablo know .)

The next pre-release of Python 3.10 will be 3.10.0a6, currently scheduled
for 2021-03-01.
And now for something completely different

The Chandrasekhar limit is the maximum mass of a stable white dwarf star.
White dwarfs resist gravitational collapse primarily through electron
degeneracy pressure, compared to main sequence stars, which resist collapse
through thermal pressure. The Chandrasekhar limit is the mass above which
electron degeneracy pressure in the star’s core is insufficient to balance
the star’s own gravitational self-attraction. Consequently, a white dwarf
with a mass greater than the limit is subject to further gravitational
collapse, evolving into a different type of stellar remnant, such as a
neutron star or black hole. Those with masses up to the limit remain stable
as white dwarfs. The currently accepted value of the Chandrasekhar limit is
about 1.4 M☉ (2.765×1030 kg). So we can be safe knowing that our sun is not
going to become a black hole!

Regards from cloudy London,

Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/UV72JXDKJYTETYQUCU36RXQCGEXGSIP2/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [ Release ] Python 3.10a5 and release blockers

2021-02-01 Thread Pablo Galindo Salgado

Hi everyone,

I am prepared to start the release process for Python 3.10 a5 but there are
several
issues marked as release blockers that affect 3.10:

* https://bugs.python.org/issue38302
* https://bugs.python.org/issue42634
* https://bugs.python.org/issue41490
* https://bugs.python.org/issue42967
* https://bugs.python.org/issue42899

Although release blockers mainly apply to important releases, there are two
are security issues and some
of the rest involve changes in bytecode or the tracing machinery, so I
would prefer if these issues are addressed
before making a new release as many maintainers are waiting for the next
alpha to test again the bugs that they
reported.

Please, if you are involved in any of these issues try to see if is
possible to address them or if you think
is ok to release the alpha without a fix, please, drop me an email stating
so.

Thanks,

Regards from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/ZVOFYB5K6UZZLQXQCCCWAJNLTMBF5Z63/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.10.0a4 is now available

2021-01-04 Thread Pablo Galindo Salgado

Happy new year to all of you. I hope you all have a great start of the
year! And how to best celebrate that we have left 2020 behind that with a
new Python alpha release? :)  Go get it here:

https://www.python.org/downloads/release/python-3100a4/


*Major new features of the 3.10 series, compared to 3.9*
Python 3.10 is still in development. This releasee, 3.10.0a4 is the second
of six 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 (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04). 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.10 are still being planned and written.
Among the new major
new features and changes so far:

* PEP 623 – Remove wstr from Unicode
* PEP 604 – Allow writing union types as X | Y
* PEP 612 – Parameter Specification Variables
* PEP 626 – Precise line numbers for debugging and other tools.
* bpo-38605: from __future__ import annotations (PEP 563) is now the
default.
* PEP 618 – Add Optional Length-Checking To zip.

(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.10 will be 3.10.0a5, currently scheduled
for 2021-02-01.


*And now for something completely different*
The Majumdar–Papapetrou spacetime
<https://en.wikipedia.org/wiki/Sudhansu_Datta_Majumdar#Majumdar%E2%80%93Papapetrou_solution>
is
one surprising solution of the coupled Einstein-Maxwell equations that
describe a cluster of static charged black holes with the gravitational and
the electrostatic forces cancelling each other out. Each one of these many
black holes of the multi-black holes system has a spherical topology and
follows the Reissner–Nordström metric
<https://en.wikipedia.org/wiki/Reissner%E2%80%93Nordstr%C3%B6m_metric>.
Unsurprisingly, the movement of a test particle in such spacetime is not
only a very chaotic system but also has some fractals
<https://arxiv.org/abs/gr-qc/9502014> hiding the complexity of its movement.

Regards from cold London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/HPZ7Z62WGFZKSFT2Z2G4ZGWGONWFJ6B7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] Python 3.9.1 is now available, together with 3.10.0a3 and 3.8.7rc1

2020-12-07 Thread Pablo Galindo Salgado

It's starting to get very cold (at least on the Northern hemisphere) so we
have been carefully packaging a total of three new Python releases to keep
you warm these days!

Python 3.9.1 is the first maintenance release of Python 3.9, and also the
first version of Python to support macOS 11 Big Sur natively on Apple
Silicon. Go get it here:

https://www.python.org/downloads/release/python-391/

Maintenance releases for the 3.9 series will continue at regular bi-monthly
intervals, with **3.9.2** planned for Monday, 2021-02-08.

Python 3.10a3 is the third alpha release of Python 3.10. You can get it
here:

https://www.python.org/downloads/release/python-3100a3/

Python 3.10a3 is the release preview of the next maintenance release of
Python 3.8. You can get it here:

https://www.python.org/downloads/release/python-387rc1/

Assuming no critical problems are found prior to **2020-12-21** , the
currently scheduled release date for **3.8.7** , no code changes are
planned between this release candidate and the final release. That being
said, please keep in mind that this is a pre-release of 3.8.7 and as such
its main purpose is testing.

Your friendly release team,
Ned Deily, Steve Dower, Pablo Galindo, Łukasz Langa
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/MCDBXKUBRCWL6M5W6A6MME7FGMBZMVR6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Vote to promote Batuhan Taşkaya

2020-10-30 Thread Pablo Galindo Salgado

Correction:

> Guido and I have opened a poll to promote Batuhan Taşkaya as a core
developer.

is just me the one proposing the promotion (copy-paste error), although
Guido had the same idea as you can see in the thread :)

Pablo Galindo Salgado


On Fri, 30 Oct 2020 at 10:30, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> Guido and I have opened a poll to promote Batuhan Taşkaya as a core
> developer.  Please read more and vote here:
>
> https://discuss.python.org/t/vote-to-promote-batuhan-taskaya/5592
>
> Thank you!
>
> Regards from cloudy London,
> Pablo Galindo Salgado
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/56FLBWZL63UQOWFHCKAZOVOJKQWGVBWY/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Batuhan Taşkaya

2020-10-30 Thread Pablo Galindo Salgado

Hi everyone,

Guido and I have opened a poll to promote Batuhan Taşkaya as a core
developer.  Please read more and vote here:

https://discuss.python.org/t/vote-to-promote-batuhan-taskaya/5592

Thank you!

Regards from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TFHJA7CFQBTCPJTPC5KPAUB2YQUV4ZO3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

2020-10-16 Thread Pablo Galindo Salgado

> We should simply mark the github actions "Tests / Ubuntu" CI as required.

+1 I completely agree with everything Gregory said.


On Fri, 16 Oct 2020 at 19:36, Gregory P. Smith  wrote:

>
>
> On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner 
> wrote:
>
>> Hi,
>>
>> Python has no mandatory Linux CI job on pull requests anymore. Right
>> now Windows (x64) remains the only mandatory job. Please be careful to
>> manually check other CI before merging a PR.
>>
>> --
>>
>> We had to deal with at least 3 different issues on the Travis CI over
>> the last 6 months. The latest one (3rd issue) is on the Travis CI side
>> and is known for months. Sometimes, a Travis CI build completes but
>> the GitHub pull request is never updated. Since Travis CI was
>> mandatory, it was never possible to merge some pull requests. I also
>> noticed a 4th bug, sometimes a PR gets *two* Travis CI jobs on a PR
>> for the same Travis CI build, only one is updated, and so again, the
>> PR cannot be merged.
>>
>> For all these reasons, Travis CI was made optional.
>>
>> I would be nice to have a mandatory Linux job: "Tests / Ubuntu
>> (pull_request)" is a good candidate. But I didn't check if it's
>> reliable or not.
>>
>
> We should simply mark the github actions "Tests / Ubuntu" CI as required.
>
> If we wind up not liking the behavior we can go back on it while we work
> something else out.  But it seems dangerous to not have any blocking Linux
> CI.  Linux is our most important platform.  With our dev sprint next week
> we'll discover if it gets in our way more often than helps rather quickly.
>
> I cannot rightfully apply an automerge label to a code PR so long as we
> lack Linux CI to block a merge.
>
> -gps
>
>
>>
>> See https://github.com/python/core-workflow/issues/377 for the
>> discussion.
>>
>> Note: if someone manages to fix all Travis CI issues, we can
>> reconsider making it mandatory again. But it seems like most people
>> who tried (included me) are tired or bored by Travis CI.
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> python-committers mailing list -- python-committers@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-committers@python.org/message/JR7HIQHVECHPKH2LE46EACN73KCBLVKE/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/7YTWVS5OXH3NJQBSG55QBSXOMD6RECFG/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/PRZ6USPKAEVZHBO5MUWYDK37O3PYBSG4/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Performance benchmarks for 3.9

2020-10-14 Thread Pablo Galindo Salgado

> Would it be possible instead to run git-bisect for only a _particular_
benchmark? It seems that may be all that’s needed to track down particular
regressions. Also, if e.g. git-bisect is used it wouldn’t be every e.g.
10th revision but rather O(log(n)) revisions.

That only works if there is a single change that produced the issue and not
many small changes that have a cumulative effect, which is normally the
case. Also, it does not work (is more tricky to make it work) if the issue
was introduced, then fixed somehow and then introduced again or in a worse
way.

On Wed, 14 Oct 2020 at 18:58, Chris Jerdonek 
wrote:

> MOn Wed, Oct 14, 2020 at 8:03 AM Pablo Galindo Salgado <
> pablog...@gmail.com> wrote:
>
>> > Would it be possible rerun the tests with the current
>> setup for say the last 1000 revisions or perhaps a subset of these
>> (e.g. every 10th revision) to try to binary search for the revision which
>> introduced the change ?
>>
>> Every run takes 1-2 h so doing 1000 would be certainly time-consuming :)
>>
>
> Would it be possible instead to run git-bisect for only a _particular_
> benchmark? It seems that may be all that’s needed to track down particular
> regressions. Also, if e.g. git-bisect is used it wouldn’t be every e.g.
> 10th revision but rather O(log(n)) revisions.
>
> —Chris
>
>
>
>
> That's why from now on I am trying to invest in daily builds for master,
>> so we can answer that exact question if we detect regressions in the
>> future.
>>
>>
>> On Wed, 14 Oct 2020 at 15:04, M.-A. Lemburg  wrote:
>>
>>> On 14.10.2020 16:00, Pablo Galindo Salgado wrote:
>>> >> Would it be possible to get the data for older runs back, so that
>>> > it's easier to find the changes which caused the slowdown ?
>>> >
>>> > Unfortunately no. The reasons are that that data was misleading because
>>> > different points were computed with a different version of
>>> pyperformance and
>>> > therefore with different packages (and therefore different code). So
>>> the points
>>> > could not be compared among themselves.
>>> >
>>> > Also, past data didn't include 3.9 commits because the data gathering
>>> was not
>>> > automated and it didn't run in a long time :(
>>>
>>> Make sense.
>>>
>>> Would it be possible rerun the tests with the current
>>> setup for say the last 1000 revisions or perhaps a subset of these
>>> (e.g. every 10th revision) to try to binary search for the revision which
>>> introduced the change ?
>>>
>>> > On Wed, 14 Oct 2020 at 14:57, M.-A. Lemburg >> > <mailto:m...@egenix.com>> wrote:
>>> >
>>> > Hi Pablo,
>>> >
>>> > thanks for pointing this out.
>>> >
>>> > Would it be possible to get the data for older runs back, so that
>>> > it's easier to find the changes which caused the slowdown ?
>>> >
>>> > Going to the timeline, it seems that the system only has data
>>> > for Oct 14 (today):
>>> >
>>> >
>>> https://speed.python.org/timeline/#/?exe=12&ben=regex_dna&env=1&revs=1000&equid=off&quarts=on&extr=on&base=none
>>> >
>>> > In addition to unpack_sequence, the regex_dna test has slowed
>>> > down a lot compared to Py3.8.
>>> >
>>> >
>>> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_unpack_sequence.py
>>> >
>>> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_regex_dna.py
>>> >
>>> > Thanks.
>>> >
>>> > On 14.10.2020 15:16, Pablo Galindo Salgado wrote:
>>> > > Hi!
>>> > >
>>> > > I have updated the branch benchmarks in the pyperformance server
>>> and now they
>>> > > include 3.9. There are
>>> > > some benchmarks that are faster but on the other hand some
>>> benchmarks are
>>> > > substantially slower, pointing
>>> > > at a possible performance regression in 3.9 in some aspects. In
>>> particular
>>> > some
>>> > > tests like "unpack sequence" are
>>> > > almost 20% slower. As there are some other tests were 3.9 is
>>> faster, is
>>> > not fair
>>> > > to conclude that 3.9 is slower,

[python-committers] Re: Performance benchmarks for 3.9

2020-10-14 Thread Pablo Galindo Salgado

>  I wouldn't worry about a small regression on a micro- or mini-benchmark
while the overall picture is
stable.

Absolutely, I agree is not something to *worry* but I think it makes sense
to investigate as
the possible fix may be trivial. Part of the reason I wanted to recompute
them was because
the micro-benchmarks published in the What's new of 3.9 were confusing a
lot of users that
were thinking if 3.9 was slower.

On Wed, 14 Oct 2020 at 15:14, Antoine Pitrou  wrote:

>
> Le 14/10/2020 à 15:16, Pablo Galindo Salgado a écrit :
> > Hi!
> >
> > I have updated the branch benchmarks in the pyperformance server and now
> > they include 3.9. There are
> > some benchmarks that are faster but on the other hand some benchmarks
> > are substantially slower, pointing
> > at a possible performance regression in 3.9 in some aspects. In
> > particular some tests like "unpack sequence" are
> > almost 20% slower. As there are some other tests were 3.9 is faster, is
> > not fair to conclude that 3.9 is slower, but
> > this is something we should look into in my opinion.
> >
> > You can check these benchmarks I am talking about by:
> >
> > * Go here: https://speed.python.org/comparison/
> > * In the left bar, select "lto-pgo latest in branch '3.9'" and "lto-pgo
> > latest in branch '3.8'"
> > * To better read the plot, I would recommend to select a "Normalization"
> > to the 3.8 branch (this is in the top part of the page)
> >and to check the "horizontal" checkbox.
>
> Those numbers tell me that it's a wash.  I wouldn't worry about a small
> regression on a micro- or mini-benchmark while the overall picture is
> stable.
>
> Regards
>
> Antoine.
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/WMNBN4LI5W7U5HKPJWQOHGZXK4X3IRHV/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/BZVCEUK42OZEN733LZB6OYXDV22GGXLL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Performance benchmarks for 3.9

2020-10-14 Thread Pablo Galindo Salgado

> Would it be possible rerun the tests with the current
setup for say the last 1000 revisions or perhaps a subset of these
(e.g. every 10th revision) to try to binary search for the revision which
introduced the change ?

Every run takes 1-2 h so doing 1000 would be certainly time-consuming :)

That's why from now on I am trying to invest in daily builds for master,
so we can answer that exact question if we detect regressions in the future.


On Wed, 14 Oct 2020 at 15:04, M.-A. Lemburg  wrote:

> On 14.10.2020 16:00, Pablo Galindo Salgado wrote:
> >> Would it be possible to get the data for older runs back, so that
> > it's easier to find the changes which caused the slowdown ?
> >
> > Unfortunately no. The reasons are that that data was misleading because
> > different points were computed with a different version of pyperformance
> and
> > therefore with different packages (and therefore different code). So the
> points
> > could not be compared among themselves.
> >
> > Also, past data didn't include 3.9 commits because the data gathering
> was not
> > automated and it didn't run in a long time :(
>
> Make sense.
>
> Would it be possible rerun the tests with the current
> setup for say the last 1000 revisions or perhaps a subset of these
> (e.g. every 10th revision) to try to binary search for the revision which
> introduced the change ?
>
> > On Wed, 14 Oct 2020 at 14:57, M.-A. Lemburg  > <mailto:m...@egenix.com>> wrote:
> >
> > Hi Pablo,
> >
> > thanks for pointing this out.
> >
> > Would it be possible to get the data for older runs back, so that
> > it's easier to find the changes which caused the slowdown ?
> >
> > Going to the timeline, it seems that the system only has data
> > for Oct 14 (today):
> >
> >
> https://speed.python.org/timeline/#/?exe=12&ben=regex_dna&env=1&revs=1000&equid=off&quarts=on&extr=on&base=none
> >
> > In addition to unpack_sequence, the regex_dna test has slowed
> > down a lot compared to Py3.8.
> >
> >
> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_unpack_sequence.py
> >
> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_regex_dna.py
> >
> > Thanks.
> >
> > On 14.10.2020 15:16, Pablo Galindo Salgado wrote:
> > > Hi!
> > >
> > > I have updated the branch benchmarks in the pyperformance server
> and now they
> > > include 3.9. There are
> > > some benchmarks that are faster but on the other hand some
> benchmarks are
> > > substantially slower, pointing
> > > at a possible performance regression in 3.9 in some aspects. In
> particular
> > some
> > > tests like "unpack sequence" are
> > > almost 20% slower. As there are some other tests were 3.9 is
> faster, is
> > not fair
> > > to conclude that 3.9 is slower, but
> > > this is something we should look into in my opinion.
> > >
> > > You can check these benchmarks I am talking about by:
> > >
> > > * Go here: https://speed.python.org/comparison/
> > > * In the left bar, select "lto-pgo latest in branch '3.9'" and
> "lto-pgo latest
> > > in branch '3.8'"
> > > * To better read the plot, I would recommend to select a
> "Normalization"
> > to the
> > > 3.8 branch (this is in the top part of the page)
> > >and to check the "horizontal" checkbox.
> > >
> > > These benchmarks are very stable: I have executed them several
> times over the
> > > weekend yielding the same results and,
> > > more importantly, they are being executed on a server specially
> prepared to
> > > running reproducible benchmarks: CPU affinity,
> > > CPU isolation, CPU pinning for NUMA nodes, CPU frequency is fixed,
> CPU
> > governor
> > > set to performance mode, IRQ affinity is
> > > disabled for the benchmarking CPU nodes...etc so you can trust
> these numbers.
> > >
> > > I kindly suggest for everyone interested in trying to improve the
> 3.9 (and
> > > master) performance, to review these benchmarks
> > > and try to identify the problems and fix them or to find what
> changes
> > introduced
> > > the regressions in the first place. All benchmarks
> >

[python-committers] Re: Performance benchmarks for 3.9

2020-10-14 Thread Pablo Galindo Salgado

> Would it be possible to get the data for older runs back, so that
it's easier to find the changes which caused the slowdown ?

Unfortunately no. The reasons are that that data was misleading because
different points were computed with a different version of pyperformance
and therefore with different packages (and therefore different code). So
the points could not be compared among themselves.

Also, past data didn't include 3.9 commits because the data gathering was
not automated and it didn't run in a long time :(


On Wed, 14 Oct 2020 at 14:57, M.-A. Lemburg  wrote:

> Hi Pablo,
>
> thanks for pointing this out.
>
> Would it be possible to get the data for older runs back, so that
> it's easier to find the changes which caused the slowdown ?
>
> Going to the timeline, it seems that the system only has data
> for Oct 14 (today):
>
>
> https://speed.python.org/timeline/#/?exe=12&ben=regex_dna&env=1&revs=1000&equid=off&quarts=on&extr=on&base=none
>
> In addition to unpack_sequence, the regex_dna test has slowed
> down a lot compared to Py3.8.
>
>
> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_unpack_sequence.py
>
> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_regex_dna.py
>
> Thanks.
>
> On 14.10.2020 15:16, Pablo Galindo Salgado wrote:
> > Hi!
> >
> > I have updated the branch benchmarks in the pyperformance server and now
> they
> > include 3.9. There are
> > some benchmarks that are faster but on the other hand some benchmarks are
> > substantially slower, pointing
> > at a possible performance regression in 3.9 in some aspects. In
> particular some
> > tests like "unpack sequence" are
> > almost 20% slower. As there are some other tests were 3.9 is faster, is
> not fair
> > to conclude that 3.9 is slower, but
> > this is something we should look into in my opinion.
> >
> > You can check these benchmarks I am talking about by:
> >
> > * Go here: https://speed.python.org/comparison/
> > * In the left bar, select "lto-pgo latest in branch '3.9'" and "lto-pgo
> latest
> > in branch '3.8'"
> > * To better read the plot, I would recommend to select a "Normalization"
> to the
> > 3.8 branch (this is in the top part of the page)
> >and to check the "horizontal" checkbox.
> >
> > These benchmarks are very stable: I have executed them several times
> over the
> > weekend yielding the same results and,
> > more importantly, they are being executed on a server specially prepared
> to
> > running reproducible benchmarks: CPU affinity,
> > CPU isolation, CPU pinning for NUMA nodes, CPU frequency is fixed, CPU
> governor
> > set to performance mode, IRQ affinity is
> > disabled for the benchmarking CPU nodes...etc so you can trust these
> numbers.
> >
> > I kindly suggest for everyone interested in trying to improve the 3.9
> (and
> > master) performance, to review these benchmarks
> > and try to identify the problems and fix them or to find what changes
> introduced
> > the regressions in the first place. All benchmarks
> > are the ones being executed by the pyperformance suite
> > (https://github.com/python/pyperformance) so you can execute them
> > locally if you need to.
> >
> > ---
> >
> > On a related note, I am also working on the speed.python.org
> > <http://speed.python.org> server to provide more automation and
> > ideally some integrations with GitHub to detect performance regressions.
> For
> > now, I have done the following:
> >
> > * Recompute benchmarks for all branches using the same version of
> > pyperformance (except master) so they can
> >be compared with each other. This can only be seen in the "Comparison"
> > tab: https://speed.python.org/comparison/
> > * I am setting daily builds of the master branch so we can detect
> performance
> > regressions with daily granularity. These
> >daily builds will be located in the "Changes" and "Timeline" tabs
> > (https://speed.python.org/timeline/).
> > * Once the daily builds are working as expected, I plan to work on
> trying to
> > automatically comment or PRs or on bpo if
> > we detect that a commit has introduced some notable performance
> regression.
> >
> > Regards from sunny London,
> > Pablo Galindo Salgado.
> >
> > ___
> > python-committers mailing list -- p

[python-committers] Re: Performance benchmarks for 3.9

2020-10-14 Thread Pablo Galindo Salgado

> The performance figures in the Python 3.9 "What's New"

Those are also micro-benchmarks, which can have no effect at all on
macro-benchmarks. The ones I am
linking are almost all macro-benchmarks, so, unfortunately, the ones
in Python 3.9 "What's New" are
not lying and they seem to be correlated to the same issue.

Also although they are not incorrect, those benchmarks in the Python 3.9
"What's New"  were not executed with LTO/PGO/CPU isolation...etc so I would
kindly suggest taking the ones in the speed.python.org as the canonical
ones if they start
to differ in any way.

Pablo

On Wed, 14 Oct 2020 at 14:25, Paul Moore  wrote:

> The performance figures in the Python 3.9 "What's New" (here -
> https://docs.python.org/3/whatsnew/3.9.html#optimizations) did look
> oddly like a lot of things went slower, to me. I assumed I'd misread
> the figures, and moved on, but maybe I was wrong to do so...
>
> Paul
>
> On Wed, 14 Oct 2020 at 14:17, Pablo Galindo Salgado 
> wrote:
> >
> > Hi!
> >
> > I have updated the branch benchmarks in the pyperformance server and now
> they include 3.9. There are
> > some benchmarks that are faster but on the other hand some benchmarks
> are substantially slower, pointing
> > at a possible performance regression in 3.9 in some aspects. In
> particular some tests like "unpack sequence" are
> > almost 20% slower. As there are some other tests were 3.9 is faster, is
> not fair to conclude that 3.9 is slower, but
> > this is something we should look into in my opinion.
> >
> > You can check these benchmarks I am talking about by:
> >
> > * Go here: https://speed.python.org/comparison/
> > * In the left bar, select "lto-pgo latest in branch '3.9'" and "lto-pgo
> latest in branch '3.8'"
> > * To better read the plot, I would recommend to select a "Normalization"
> to the 3.8 branch (this is in the top part of the page)
> >and to check the "horizontal" checkbox.
> >
> > These benchmarks are very stable: I have executed them several times
> over the weekend yielding the same results and,
> > more importantly, they are being executed on a server specially prepared
> to running reproducible benchmarks: CPU affinity,
> > CPU isolation, CPU pinning for NUMA nodes, CPU frequency is fixed, CPU
> governor set to performance mode, IRQ affinity is
> > disabled for the benchmarking CPU nodes...etc so you can trust these
> numbers.
> >
> > I kindly suggest for everyone interested in trying to improve the 3.9
> (and master) performance, to review these benchmarks
> > and try to identify the problems and fix them or to find what changes
> introduced the regressions in the first place. All benchmarks
> > are the ones being executed by the pyperformance suite (
> https://github.com/python/pyperformance) so you can execute them
> > locally if you need to.
> >
> > ---
> >
> > On a related note, I am also working on the speed.python.org server to
> provide more automation and
> > ideally some integrations with GitHub to detect performance regressions.
> For now, I have done the following:
> >
> > * Recompute benchmarks for all branches using the same version of
> pyperformance (except master) so they can
> >be compared with each other. This can only be seen in the
> "Comparison" tab: https://speed.python.org/comparison/
> > * I am setting daily builds of the master branch so we can detect
> performance regressions with daily granularity. These
> >daily builds will be located in the "Changes" and "Timeline" tabs (
> https://speed.python.org/timeline/).
> > * Once the daily builds are working as expected, I plan to work on
> trying to automatically comment or PRs or on bpo if
> > we detect that a commit has introduced some notable performance
> regression.
> >
> > Regards from sunny London,
> > Pablo Galindo Salgado.
> > ___
> > python-committers mailing list -- python-committers@python.org
> > To unsubscribe send an email to python-committers-le...@python.org
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/G3LB4BCAY7T7WG22YQJNQ64XA4BXBCT4/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/4OG362VITFQMDLZRWVHMEAQQIIAX2KOT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Performance benchmarks for 3.9

2020-10-14 Thread Pablo Galindo Salgado

Hi!

I have updated the branch benchmarks in the pyperformance server and now
they include 3.9. There are
some benchmarks that are faster but on the other hand some benchmarks are
substantially slower, pointing
at a possible performance regression in 3.9 in some aspects. In particular
some tests like "unpack sequence" are
almost 20% slower. As there are some other tests were 3.9 is faster, is not
fair to conclude that 3.9 is slower, but
this is something we should look into in my opinion.

You can check these benchmarks I am talking about by:

* Go here: https://speed.python.org/comparison/
* In the left bar, select "lto-pgo latest in branch '3.9'" and "lto-pgo
latest in branch '3.8'"
* To better read the plot, I would recommend to select a "Normalization" to
the 3.8 branch (this is in the top part of the page)
   and to check the "horizontal" checkbox.

These benchmarks are very stable: I have executed them several times over
the weekend yielding the same results and,
more importantly, they are being executed on a server specially prepared to
running reproducible benchmarks: CPU affinity,
CPU isolation, CPU pinning for NUMA nodes, CPU frequency is fixed, CPU
governor set to performance mode, IRQ affinity is
disabled for the benchmarking CPU nodes...etc so you can trust these
numbers.

I kindly suggest for everyone interested in trying to improve the 3.9 (and
master) performance, to review these benchmarks
and try to identify the problems and fix them or to find what changes
introduced the regressions in the first place. All benchmarks
are the ones being executed by the pyperformance suite (
https://github.com/python/pyperformance) so you can execute them
locally if you need to.

---

On a related note, I am also working on the speed.python.org server to
provide more automation and
ideally some integrations with GitHub to detect performance regressions.
For now, I have done the following:

* Recompute benchmarks for all branches using the same version of
pyperformance (except master) so they can
   be compared with each other. This can only be seen in the "Comparison"
tab: https://speed.python.org/comparison/
* I am setting daily builds of the master branch so we can detect
performance regressions with daily granularity. These
   daily builds will be located in the "Changes" and "Timeline" tabs (
https://speed.python.org/timeline/).
* Once the daily builds are working as expected, I plan to work on trying
to automatically comment or PRs or on bpo if
we detect that a commit has introduced some notable performance regression.

Regards from sunny London,
Pablo Galindo Salgado.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/G3LB4BCAY7T7WG22YQJNQ64XA4BXBCT4/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Thank you Larry Hastings!

2020-10-05 Thread Pablo Galindo Salgado

As someone that went through doing a release just now and now what it
entailsthanks a lot for all the work, Larry! :)

On Mon, 5 Oct 2020 at 19:39, Barry Warsaw  wrote:

> They say being a Python Release Manager is a thankless job, so the Python
> Secret Underground (PSU), which emphatically does not exist, hereby
> officially doesn’t thank Larry for his years of diligent service as the
> Python 3.4 and 3.5 release manager.
>
> On the other hand, the Python Steering Council, Python Software
> Foundation, and worldwide Python community, all of which emphatically *do*
> exist, all extend our heartfelt thanks to Larry for his excellent
> stewardship of Python 3.4 and 3.5!
>
> Python 3.4 and 3.5 were both pivotal releases.  While the features of
> these two releases are too numerous to mention here, they introduced such
> staples as:
>
> * asyncio
> * enum
> * pathlib
> * async and await keywords
> * matrix multiplication operators
> * typing and zipapp modules
>
> and so much more.  For details, see:
>
> * https://docs.python.org/3/whatsnew/3.4.html
> * https://docs.python.org/3/whatsnew/3.5.html
>
> Larry’s first official release of 3.4.0a1 was on 2013-08-03 and his last
> Python 3.5.10 release was 2020-09-05.  That’s 7 years of exemplary release
> managing!
>
> Larry, from all of us, and from me personally, thank you so much for your
> invaluable contributions to Python.  Enjoy your retirement!
>
> Cheers,
> -Barry (on behalf of the PSC and PSF)
>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/QGIHFU64TBYT56K6M5A5LYTYTSVFKHWQ/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JDQMPPBGVKKUR5CWUANYAAYU3EQPFR42/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Lysandros Nikolaou

2020-06-15 Thread Pablo Galindo Salgado

Hi everyone,

Guido and I have opened a poll to promote Lysandros Nikolaou as a core
developer.  Please read more and vote here:

https://discuss.python.org/t/vote-to-promote-lysandros-nikolaou/4445

Thank you!

Regards from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/MCWANHARO4EASQQ2EPUHZK7PITQDQJWS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Lysandros Nikolaou got the bug triage permission!

2020-04-22 Thread Pablo Galindo Salgado

Hi,

I am giving triage privileges to Lysandros Nikolaou (lys.nikolaou on bpo,
lysnikolaou in GitHub) .

Lysandros has been working with Guido and myself in PEP 617 for quite a
long time, being an indispensable
member of the team. In all this time he has proven to have a great set of
technical skills both in C and Python
while being a real pleasure to work with. Lysandros has also learned
greatly about the processes, workflow
and values of the core team and always has great enthusiasm and will to
improve. I can say with confidence
that Lysandros is an excellent developer, a compassionate person and
someone who has shown to care about
Python and its community.

As usual, I will ask him to ask me before closing bugs for the first weeks.

Congrats, Lysandros!
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/MOOCZENDBLSYEXD56YYSWGJU3C2KKOKJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

1 2 >

1 - 100 of 115 matches

Mail list logo