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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P4JHHHAAO4L4KFZQ6PX5J3JRPAZUXJWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 701 – Syntactic formalization of f-strings

[Pablo Galindo Salgado]

Hi everyone,

For those that are not following the discussion in the discourse thread, I
am holding a poll to get an idea of the community opinions on how quotes
should work in nested f-strings for PEP 701:

https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046/24

For us is very important to have everyone represented and every opinion
heard and taken into consideration so feel free to vote in the poll leaving
your opinion. But please, **read first the PEP and the previous
discussion**. This is very important to get the context and previous
arguments in favour and against the different options.

Thanks a lot for your help!

Regards from cloudy London,
Pablo Galindo Salgado

On Mon, 19 Dec 2022 at 17:59, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> I am very excited to share with you a PEP that Batuhan Taskaya, Lysandros
> Nikolaou and myself have been working on recently: PEP 701 - PEP 701 –
> Syntactic formalization of f-strings <https://peps.python.org/pep-0701/>.
>
> We believe this will be a great improvement in both the maintainability of
> CPython and the usability of f-strings.
>
> We look forward to hearing what you think about this and to get your
> feedback!
>
> *Here is a TLDR for your convenience:*
>
>- The PEP proposes a formalized grammar for f-strings in Python by
>adding f-strings directly into the Grammar instead of using a two-pass
>hand-written parser.
>- This would lift some existing restrictions for f-strings that (we
>believe) will improve the user experience with f-strings.
>- Other benefits include:
>   - Reduced maintenance costs for f-string parsing code as well as
>   improved usability for users and library developers.
>   - Better error messages involving f-strings by leveraging the PEG
>   parser machinery.
>   - The proposed changes would improve the overall consistency of the
>   language and provide a way for alternative implementations to accurately
>   implement f-strings.
>
> *** IMPORTANT: direct all discussions to the discussion thread on
> discourse: 
> https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046
> <https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046>
> ***
>
> Thanks a lot, everyone for your time!
> Regards from rainy London,
> Pablo Galindo Salgado
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q22YQBHTVRUFKRMAETL3CDR7JN3YRJAG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 701 – Syntactic formalization of f-strings

[Pablo Galindo Salgado]

Hi everyone,

I am very excited to share with you a PEP that Batuhan Taskaya, Lysandros
Nikolaou and myself have been working on recently: PEP 701 - PEP 701 –
Syntactic formalization of f-strings <https://peps.python.org/pep-0701/>.

We believe this will be a great improvement in both the maintainability of
CPython and the usability of f-strings.

We look forward to hearing what you think about this and to get your
feedback!

*Here is a TLDR for your convenience:*

   - The PEP proposes a formalized grammar for f-strings in Python by
   adding f-strings directly into the Grammar instead of using a two-pass
   hand-written parser.
   - This would lift some existing restrictions for f-strings that (we
   believe) will improve the user experience with f-strings.
   - Other benefits include:
  - Reduced maintenance costs for f-string parsing code as well as
  improved usability for users and library developers.
  - Better error messages involving f-strings by leveraging the PEG
  parser machinery.
  - The proposed changes would improve the overall consistency of the
  language and provide a way for alternative implementations to accurately
  implement f-strings.

*** IMPORTANT: direct all discussions to the discussion thread on
discourse: 
https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046
<https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046>
***

Thanks a lot, everyone for your time!
Regards from rainy London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IU4O3GFGWJ4FWXXC2TVB4CNPZI3KFBQM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: probably nothing but just in case.... 503 Service Unavailable error

[Pablo Galindo Salgado]

Hi Wonsuk,

I am doing some maintenance work on the builedbot fleet so some pages
may be unavailable temporarily, no need to deprecate it ;)

If you visit https://buildbot.python.org/all/#/grid 
<https://buildbot.python.org/all/#/grid> it works (as of me writing this email).

Thanks for contacting us.

Regards from snowy London,
Pablo Galindo Salgado

> On 15 Dec 2022, at 07:12, wonsuk yang  wrote:
> 
> hi! thank you for amazing community!
> 
> the python community is the light and the salt for me!
> 
> the site  https://buildbot.python.org/all/#/grid
> 
> from https://www.python.org/dev/buildbot/
> 
> shows the error of
> 
> "503 Service Unavailable; No server is available to handle this request."
> 
> i reckon the site might be deprecated yet report this just in case
> 
> sorry to bother if it is already known!
> 
> hope the best
> 
> w. yang
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/UNZIOIP3RCO3775KAEMMP6YFLLNIN4UW/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ODGXZA5323EHRQD6ALX4WJWZD4UXK7NT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] August steering council update

[Pablo Galindo Salgado]

ckward compatibility policy and decided that we
  should gather input from the core devs on that. It was proposed to ask people
  attending the core dev sprint as a first measure.

## 2022-08-22

* The SC met with the Developer in Residence and discussed:
* Bot/CLA hosting and Heroku tiers.
* EdgeDB update for the CLA bot.
* Blog posts and talk ideas.
* Typing PEPs.
* The SC discussed details about the organization of the 2022 Core Dev sprints.
* The SC discussed resources for mentoring and how to help core devs mentor new
  contributors.
* The SC discussed [PEP 674 – Disallow using macros as
  l-values](https://peps.python.org/pep-0674/) and the changes that were merged
  without a PEP accepted in 3.11. Pablo will answer [to the discussion that
  Victor started in
  
discourse](https://discuss.python.org/t/pep-674-disallow-using-macros-as-l-values-and-python-3-11/18297/14).
* The SC discussed several aspects on how to deal with breaking changes. It was
  decided that this will be a discussion point with the rest of the core devs
  in the core dev sprint.


In representation of the Steering Council,

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

[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar

[Pablo Galindo Salgado]

Just be aware that the C tokenizer interface is NOT a public interface and is there only so we can test the C tokenizer itself. This can and will break at any point without previous warning in any way.Pablo Galindo SalgadoOn 3 Nov 2022, at 18:10, David J W  wrote:Following up, Pablo spotted my problem with the mixup of NL & NEWLINE tokens.  I was using tokenize.py in cPython's stdlib with a simple python script to build ridiculously strict unit tests.  My solution to that problem was originally to figure out how to access cPython's internal c tokenizer but someone else did that in 3.11.   The parser is passing basic tests but I need to redo all of the tests for my tokenizer as they are flawed and also do some major housekeeping to clean up all the warnings and TODO's sprinkled throughout my code base.To hopefully avoid future problems, is Lib/symtable.py trustworthy as a way of building unit tests when I start implementing my own symbols graph/table?Thanks,    DavidOn Wed, Oct 26, 2022 at 11:57 PM Matthieu Dartiailh <m.dartia...@gmail.com> wrote:If you look at pegen, that uses the stdlib tokenizer as input, you will see that the obejct us3d to implement memoization on top of a token stream simply swallow NL (https://github.com/we-like-parsers/pegen/blob/main/src/pegen/tokenizer.py#L49). This is safe since NL has no syntactic meaning only NEWLINE does.BestMatthieuOn Thu, Oct 27, 2022, 01:59 Matthias Görgens <matthias.goerg...@gmail.com> wrote:Hi David,Could you share what you have so far, perhaps ok GitHub or so? That way it's easier to diagnose your problems. I'm reasonably familiar with Rust.Perhaps also add a minimal crashing example?Cheers,Matthias.On Thu, 27 Oct 2022, 04:52 David J W, <ward.dav...@gmail.com> wrote:Pablo,    Nl and Newline are tokens but I am interested in NEWLINE's behavior in the Python grammar, note the casing.For example in simple_stmts @ https://github.com/python/cpython/blob/main/Grammar/python.gram#L107Is that NEWLINE some sort of built in rule to the grammar?   In my project I am running into problems where the parser crashes any time there is some double like NL & N or Newline & NL but I want to nail down NEWLINE's behavior in CPython's PEG grammar.On Wed, Oct 26, 2022 at 12:51 PM Pablo Galindo Salgado <pablog...@gmail.com> wrote:Hi,

I am not sure I understand exactly what you are asking but NEWLINE is a token, not a parser rule. What decides when NEWLINE is emitted is the lexer that has nothing to do with PEG. Normally PEG parsers also acts as tokenizers but the one in cpython does not.

Also notice that CPython’s parser uses a version of the tokeniser written in C that doesn’t share code with the exposed version. You will find that the tokenizer module in the standard library actually behaves differently regarding what tokens are emitted in new lines and indentations.

The only way to be sure is check the code unfortunately.

Hope this helps.

Regards from rainy London,
Pablo Galindo Salgado

> On 26 Oct 2022, at 19:12, David J W <ward.dav...@gmail.com> wrote:
> 
> 
> I am writing a Rust version of Python for fun and I am at the parser stage of development.
> 
> I copied and modified a PEG grammar ruleset from another open source project and I've already noticed some problems (ex Newline vs NL) with how they transcribed things.
> 
> I am suspecting that CPython's grammar NEWLINE is a builtin rule for the parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to sanity check if that is right before I figure out how to hack in a NEWLINE rule and update my grammar ruleset.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LTDXZ4DS2GLICZRWYZ5PVLPBJHVGQPSS/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZZDKWS62QG3BTNIT2NYRCLRI4VJ2HBF6/
Code of Conduct: http://python.org/psf/codeofconduct/


___Python-Dev mailing list -- python-dev@python.orgTo unsubscribe send an email to pyt

[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar

[Pablo Galindo Salgado]

Hummm… he is also mentioning NL and Newline tokens and if I recall correctly those are tokens that only appear in the Python tokenizer and are emitted differently from the C one (and therefore they are not used in the grammar).Pablo Galindo SalgadoOn 26 Oct 2022, at 21:57, Guido van Rossum  wrote:I wonder if David may be struggling with the rule that a newline is significant in the grammar unless it appears inside matching brackets/parentheses/braces? I think that's in the lexer. Similarly, multiple newlines are collapsed.On Wed, Oct 26, 2022 at 1:19 PM Pablo Galindo Salgado <pablog...@gmail.com> wrote:Hi,As I mentioned, NEWLINE is a token. All uppercase words in the grammar are tokens and therefore are produced by the lexer, not the parser. Is not a built-in rule. In particular, that token is produced here:https://github.com/python/cpython/blob/6777e09166fc384ea0a4b50202c7b0bd7a23330c/Parser/tokenizer.c#L1773On Wed, 26 Oct 2022 at 20:59, David J W <ward.dav...@gmail.com> wrote:Pablo,    Nl and Newline are tokens but I am interested in NEWLINE's behavior in the Python grammar, note the casing.For example in simple_stmts @ https://github.com/python/cpython/blob/main/Grammar/python.gram#L107Is that NEWLINE some sort of built in rule to the grammar?   In my project I am running into problems where the parser crashes any time there is some double like NL & N or Newline & NL but I want to nail down NEWLINE's behavior in CPython's PEG grammar.On Wed, Oct 26, 2022 at 12:51 PM Pablo Galindo Salgado <pablog...@gmail.com> wrote:Hi,

I am not sure I understand exactly what you are asking but NEWLINE is a token, not a parser rule. What decides when NEWLINE is emitted is the lexer that has nothing to do with PEG. Normally PEG parsers also acts as tokenizers but the one in cpython does not.

Also notice that CPython’s parser uses a version of the tokeniser written in C that doesn’t share code with the exposed version. You will find that the tokenizer module in the standard library actually behaves differently regarding what tokens are emitted in new lines and indentations.

The only way to be sure is check the code unfortunately.

Hope this helps.

Regards from rainy London,
Pablo Galindo Salgado

> On 26 Oct 2022, at 19:12, David J W <ward.dav...@gmail.com> wrote:
> 
> 
> I am writing a Rust version of Python for fun and I am at the parser stage of development.
> 
> I copied and modified a PEG grammar ruleset from another open source project and I've already noticed some problems (ex Newline vs NL) with how they transcribed things.
> 
> I am suspecting that CPython's grammar NEWLINE is a builtin rule for the parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to sanity check if that is right before I figure out how to hack in a NEWLINE rule and update my grammar ruleset.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
> Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5ZV7BZOYHW3DELYIB4GKRWHUNTYW3V4K/
Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)Pronouns: he/him (why is my pronoun here?)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KUXABSTZP33ZEXB74HS5262TGNFGBCP7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TKNPRJI7QXHC73EKKTN2N5PMEX26POIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar

[Pablo Galindo Salgado]

Hi,

As I mentioned, NEWLINE is a token. All uppercase words in the grammar are
tokens and therefore are produced by the lexer, not the parser. Is not a
built-in rule. In particular, that token is produced here:

https://github.com/python/cpython/blob/6777e09166fc384ea0a4b50202c7b0bd7a23330c/Parser/tokenizer.c#L1773


On Wed, 26 Oct 2022 at 20:59, David J W  wrote:

> Pablo,
> Nl and Newline are tokens but I am interested in NEWLINE's behavior in
> the Python grammar, note the casing.
>
> For example in simple_stmts @
> https://github.com/python/cpython/blob/main/Grammar/python.gram#L107
>
> Is that NEWLINE some sort of built in rule to the grammar?   In my project
> I am running into problems where the parser crashes any time there is some
> double like NL & N or Newline & NL but I want to nail down NEWLINE's
> behavior in CPython's PEG grammar.
>
> On Wed, Oct 26, 2022 at 12:51 PM Pablo Galindo Salgado <
> pablog...@gmail.com> wrote:
>
>> Hi,
>>
>> I am not sure I understand exactly what you are asking but NEWLINE is a
>> token, not a parser rule. What decides when NEWLINE is emitted is the lexer
>> that has nothing to do with PEG. Normally PEG parsers also acts as
>> tokenizers but the one in cpython does not.
>>
>> Also notice that CPython’s parser uses a version of the tokeniser written
>> in C that doesn’t share code with the exposed version. You will find that
>> the tokenizer module in the standard library actually behaves differently
>> regarding what tokens are emitted in new lines and indentations.
>>
>> The only way to be sure is check the code unfortunately.
>>
>> Hope this helps.
>>
>> Regards from rainy London,
>> Pablo Galindo Salgado
>>
>> > On 26 Oct 2022, at 19:12, David J W  wrote:
>> >
>> > 
>> > I am writing a Rust version of Python for fun and I am at the parser
>> stage of development.
>> >
>> > I copied and modified a PEG grammar ruleset from another open source
>> project and I've already noticed some problems (ex Newline vs NL) with how
>> they transcribed things.
>> >
>> > I am suspecting that CPython's grammar NEWLINE is a builtin rule for
>> the parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to
>> sanity check if that is right before I figure out how to hack in a NEWLINE
>> rule and update my grammar ruleset.
>> > ___
>> > Python-Dev mailing list -- python-dev@python.org
>> > To unsubscribe send an email to python-dev-le...@python.org
>> > https://mail.python.org/mailman3/lists/python-dev.python.org/
>> > Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5ZV7BZOYHW3DELYIB4GKRWHUNTYW3V4K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar

[Pablo Galindo Salgado]

Hi,

I am not sure I understand exactly what you are asking but NEWLINE is a token, 
not a parser rule. What decides when NEWLINE is emitted is the lexer that has 
nothing to do with PEG. Normally PEG parsers also acts as tokenizers but the 
one in cpython does not.

Also notice that CPython’s parser uses a version of the tokeniser written in C 
that doesn’t share code with the exposed version. You will find that the 
tokenizer module in the standard library actually behaves differently regarding 
what tokens are emitted in new lines and indentations.

The only way to be sure is check the code unfortunately.

Hope this helps.

Regards from rainy London,
Pablo Galindo Salgado

> On 26 Oct 2022, at 19:12, David J W  wrote:
> 
> 
> I am writing a Rust version of Python for fun and I am at the parser stage of 
> development.
> 
> I copied and modified a PEG grammar ruleset from another open source project 
> and I've already noticed some problems (ex Newline vs NL) with how they 
> transcribed things.
> 
> I am suspecting that CPython's grammar NEWLINE is a builtin rule for the 
> parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to sanity 
> check if that is right before I figure out how to hack in a NEWLINE rule and 
> update my grammar ruleset.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YWDKMMKQJN5UY44ONDGF6VD24M7H7HYB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev

[Python-Dev] IMPORTANT: Check the 3.11.0 cherry-picks

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SB5PWB32JQHE7QFIULXIZIGUFPKSYEKP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] RELEASE MANAGEMENT: Python 3.11 release stream

[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 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, 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IXKQMO36OYE5MUN3XIGNJEOQ2VGLZKUJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EURTP5F4XUQXWVSUQ4R3UJQ5GANHHMKO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.11.0 RC2 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TKFELC4AXKSYMJXCZNZYE7O5OR7ZGTXH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Pablo Galindo Salgado]

ars, is for these 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JV3LYX3SBGMLMIK7HLNZTLFPY4RMP3NZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.10.6 is available

[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-dev@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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/H264J7IX6MYWM532ER4YH3DMW3CCHTRP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Pablo Galindo Salgado]

lly 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VCLXLDD7PQH6CVG5LBGP6EDFBHQX3F4T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NOBNKLWKMJAHGLV6GVNITUBJ7OFJLIXY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Pablo Galindo Salgado]

ing 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VD7YNBVMEPKZLRA6VOTYAQYTEZPDH6Q7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [Release] Status of Python 3.11 release

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3JWVCSBPBFWY5ZWSJ7RYB6FS5NIMCEOY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Release] Python 3.11.0b4 is still blocked

[Pablo Galindo Salgado]

Hi Petr and Miro,

Thanks for communicating your concerns regarding Fedora and the release
schedule.

>> It would be really great to get something ABI stable at Beta Freeze and
at
least an RC at the Final Freeze. If that is not realistic, we would need to
consider a revert.

I am not sure if there is some typo, but the beta freeze is the first beta.
The ABI is frozen
in the first release candidate, not in beta freeze. We won't get stable ABI
until the first RC
is released.

>> Some months sounds pretty big to me. Once the current beta is released,
I'd be
great to see some updated release schedule. We have just updated the main
Python version Fedora 37 to 3.11 and we have some deadlines I'd like not to
miss.

I understand that in the (still not decided) case that the release is
delayed will be quite
inconvenient for Fedora and other Linux distributions. I will surely take
this into account
when making a decision and I will try to avoid having to fall into this,
but please understand
that the Release Team's responsibility is ensuring a stable release, and
given the events in the
In past weeks, I do not feel comfortable with the current level of testing
so we may require more
betas.

Thanks for your understanding,
Pablo Galindo Salgado

On Mon, 4 Jul 2022 at 18:21, Petr Viktorin  wrote:

> On 04. 07. 22 19:03, Miro Hrončok wrote:
> > On 04. 07. 22 18:53, Pablo Galindo Salgado wrote:
> >> Hi Miro,
> >>
> >>  >> Are all release blockers automatically blocking the next beta?
> >>
> >> Yes.
> >>
> >>  >> Or does it mean this should not be released in final (and hence
> >> neither rc)
> >> versions?
> >>
> >> Release blockers block also beta releases (if the RM decides so).
> >>
> >>  >> Would it make sense to release 3.11.0b4 with some not-yet-fixed
> >> blockers?
> >>
> >> No, the reason is that fixes can introduce more regressions and those
> >> need to be fixed. If these fixes
> >> are pretty big we would be risking big changes in the RC phase, which
> >> we want to avoid. The idea is that
> >> the fixes to critical problems reported on beta x can be tested on
> >> beta x+1.
> >>
> >> At the end of the day, this is all subjected to the judgement of the
> >> release manager, and given how many
> >> release blockers we have been getting and how many of these have been
> >> reported past week *after* several
> >> attempts to release the next beta, I have decided to wait.
> >
> > Thanks. Understood.
> >
> >> Additionally, I am considering pushing the full release some months in
> >> the future to allow for more betas, given
> >> how unstable 3.11 is currently.
> >
> > Some months sounds pretty big to me. Once the current beta is released,
> > I'd be great to see some updated release schedule. We have just updated
> > the main Python version Fedora 37 to 3.11 and we have some deadlines I'd
> > like not to miss.
> >
> > https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
> > 2022-08-23 - Fedora 37 Beta Freeze
> > 2022-10-04 - Fedora 37 Final Freeze
> >
> > It would be really great to get something ABI stable at Beta Freeze and
> > at least an RC at the Final Freeze. If that is not realistic, we would
> > need to consider a revert.
>
> Worse than a one-time revert. With the current schedule, the  projects'
> testing phases overlap so Fedora can test rebuilding all its Python
> software with Python's alphas/betas. If the schedule is adjusted or made
> unreliable, Fedora might need to add a six-month delay and rebuild with
> final releases -- and find bugs much later.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/FRAKKZNIVUL46JLPMRR76H24RSYRQMP7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DLMOU6YL6WCFHIZYHAIZHWPYTSRT7EQI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Release] Python 3.11.0b4 is still blocked

[Pablo Galindo Salgado]

Hi Miro,

>> Are all release blockers automatically blocking the next beta?

Yes.

>> Or does it mean this should not be released in final (and hence neither
rc)
versions?

Release blockers block also beta releases (if the RM decides so).

>> Would it make sense to release 3.11.0b4 with some not-yet-fixed
blockers?

No, the reason is that fixes can introduce more regressions and those need
to be fixed. If these fixes
are pretty big we would be risking big changes in the RC phase, which we
want to avoid. The idea is that
the fixes to critical problems reported on beta x can be tested on beta x+1.

At the end of the day, this is all subjected to the judgement of the
release manager, and given how many
release blockers we have been getting and how many of these have been
reported past week *after* several
attempts to release the next beta, I have decided to wait.

Additionally, I am considering pushing the full release some months in the
future to allow for more betas, given
how unstable 3.11 is currently.

Pablo Galindo Salgado





On Mon, 4 Jul 2022 at 15:26, Miro Hrončok  wrote:

> On 24. 06. 22 14:25, Pablo Galindo Salgado wrote:
> > 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...
>
> I was thinking. Are all release blockers automatically blocking the next
> beta?
> Or does it mean this should not be released in final (and hence neither
> rc)
> versions? Would it make sense to release 3.11.0b4 with some not-yet-fixed
> blockers? Assuming those are not regressions that happened after 3.11.0b3
> was
> released.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/X7HRFQHFRA5C7CMSVFXOODG45WNRZ5UH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [Release] Python 3.11.0b4 is still blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7AT3YTUJOYMZI4VNMSJ42BE6ZNR7GANM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] IMPORTANT: Python 3.11.0b4 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ORCYBRP432J36LXP32IDX6KLRE7Z646V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms

[Pablo Galindo Salgado]

> or has at least agreed to, not sure any releases have happened since I
asked).
I did:

https://www.python.org/downloads/release/python-3110b3/#:~:text=3.11.0b3%20is%20the%20second,support%20the%20new%20feature%20release
.

On Mon, 6 Jun 2022 at 19:13, Steve Dower  wrote:

> +1. Glad it's not just me
>
> On 6/6/2022 2:36 PM, Victor Stinner wrote:
> > First, I understood that "Arbitrary Literal String Type" was adding a
> > new built-in types for "literal strings" :-) Nope. It's just about
> > type annotations ;-)
>
> I was also excited about the new built-in type :-)
>
> Pablo is already separating the PEPs in new release announcements (or
> has at least agreed to, not sure any releases have happened since I asked).
>
> But with the amount of work going on in separate venues these days,
> separating "CPython implementation" from "Language specification" from
> "Typing specification" would be helpful. (Packaging is already separate,
> but doesn't appear in release announcements anyway.)
>
> Cheers,
> Steve
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3VJEOP2VYQ66G4PS665QV52P5TGRYP5O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R3Z4V7NZ2MOCUYDZZKNJLPZIGFA6Z2GN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.10.5 is available

[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-dev@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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/V4AUICXW2EDGFK2EIDSFA6RXMNWLCC54/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deadlock when interrupting interpreter initialisation with ptrace?

[Pablo Galindo Salgado]

Hi Gabriele,

If everything you are doing is pausing and restarting, there should be no
reason
why this would interfere with anything more than if you are doing this at
any other time
other than the interpreter initialization. The only thing I can think of is
that at this stage
locking is much more common.

The other thing that could be at play is that ptrace sends SIGSTOP
on PTRACE_ATTACH but
the signal cannot be captured by the interpreter (or any other process) so
no signal handler
should be at play either.

Do you know what is involved in the deadlock (as in, what the threads are
waiting on)?

Answering your questions directly:

> However, I think this poses one question: is this behaviour from
Python to be expected or is it perhaps an indication of a potential
bug?

Is not expected or unexpected because is not something we support. Is not
also something we
explicitly forbid either, is just that there is nothing in the design or
the test suite that ensures that
this will work.

> is it acceptable that the pausing and resuming of the execution of a
thread
lead to a potential deadlock?

It depends if this is something that we can control in a reasonable way or
if this is outside our control.
It may be a bug in our code in which case we can try to fix it, but without
a more concrete pointer is
going to be complicated, especially given that is more likely that this is
outside our control.

We probably will reject any proposal to add complexity to support this use
case but we likely will
be happy to do small changes if there is something small that we do that is
preventing the use case.

Cheers from cloudy London,
Pablo Galindo Salgado


On Mon, 6 Jun 2022 at 15:38, Gabriele  wrote:

> Hi there
>
> I hope you don't mind me sharing my experience with testing the
> austinp variant of Austin with Python >=2.7,<3.11.
>
> The austinp variant is a variant of Austin
> (https://github.com/P403n1x87/austin) for Linux that uses ptrace to
> seize and interrupt/continue threads to capture native stack traces
> using libunwind. During testing, I have discovered that there are good
> chances of causing what looks like a deadlock in Python if the seizing
> and interrupting of threads happen very early when spawning a Python
> subprocess from austinp. This seems to coincide with the
> initialisation of the interpreter when modules are being loaded. To
> avoid interfering so destructively with Python, I have added a sleep
> of about 0.5s on fork to prevent sampling during this initialisation
> phase, which has helped significantly.
>
> However, I think this poses one question: is this behaviour from
> Python to be expected or is it perhaps an indication of a potential
> bug? Whilst I find it conceivable that something like this could
> happen, given the locking that happens around imports, is it
> acceptable that the pausing and resuming of the execution of a thread
> lead to a potential deadlock?
>
> Cheers,
> Gabriele
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/EWE5IK53IAME7ODZOGCQGSSP4YBE37YX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KH2CRDMPSRA4YHXQNQ4Z2WLSG3Y5IPMR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

[Pablo Galindo Salgado]

Hi Robin,

The correct range requirements are mandatory from beta 2. There will be 2
more betas after beta 3: beta4 and beta5.

Please, check out the release announcement for beta3.

Cheers,
Pablo Galindo Salgado

On Fri, 3 Jun 2022, 09:56 Robin Becker,  wrote:

> On 01/06/2022 16:58, Pablo Galindo Salgado wrote:
> > Update: we have decided to release Python 3.11.0b3. Let's hope this one
> is
> > free of the curse :)
> >
> 
>
> Hi I hade a couple of failures related to the compile failure for ASTs
> with wrongly ranged start-end attributes.
> After spending a while sorting those I hope that b3 will still work for
> those case.
>
> Will the reasonable range requirement eventually be made mandatory? It
> does seem like a good idea.
>
> Will there be an extra beta?
>
> --
> Robin Becker
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZEHVLCSEEIZXIGFQMJXT2RDOWELMKGXE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

[Pablo Galindo Salgado]

Update: we have decided to release Python 3.11.0b3. Let's hope this one is
free of the curse :)

On Wed, 1 Jun 2022 at 07:38, Miro Hrončok  wrote:

> On 01. 06. 22 0:39, Pablo Galindo Salgado wrote:
> >  > Wouldn't it be more practical to bite the bullet and release b3
> immediately
> > with this fix?
> >
> > I sympathize with the sentiment and I am sorry that
> this is not practical but I
> > am not fully convinced about the balance. Beta 3 is in one month and
> spinning
> > an entire release is a multi-hour process for at least 3 people. I will
> discuss
> > this with the release team but is unlikely.
>
> Understood. It's always a balance.
>
>
> > For testing at fedora, you can
> > temporarily patch beta2 and include this commit:
>
> Thanks. We already do that, my comment was motivated by the majority of
> upstream CI which do not use Fedora's Python 3.11 (yet?).
>
> > Just for the heads up: I have sent an email to the release team and we
> are
> > considering the proposal. Thanks for raising this with us.
>
> Awesome, thanks again.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DIECBL5OUTJLOKL637UE74CUGBDGA2VE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Expedited release of Python3.11.0b3!!

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YWAX3PNIXA6RDE2CGMGWZBFAAOM2LBA7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

[Pablo Galindo Salgado]

Just for the heads up: I have sent an email to the release team and we are
considering the proposal. Thanks for raising this with us.

On Tue, 31 May 2022 at 23:39, Pablo Galindo Salgado 
wrote:

> > Wouldn't it be more practical to bite the bullet and release b3
> immediately with this fix?
>
> I sympathize with the sentiment and I am sorry that this is not practical
> but I am not fully convinced about the balance. Beta 3 is in one month and
> spinning an entire release is a multi-hour process for at least 3 people. I
> will discuss this with the release team but is unlikely. For testing at
> fedora, you can temporarily patch beta2 and include this commit:
>
>
> https://github.com/python/cpython/commit/b425d887aa51c8e7900b08cb8df457f450f6fbfd
>
> On Wed, 1 Jun 2022 at 00:19, Miro Hrončok  wrote:
>
>> On 01. 06. 22 0:02, Pablo Galindo Salgado wrote:
>> > You may be able to work around this issue by preventing pytest to
>> rewrite the
>> > assert statements by adding `--assert=plain` to the command line
>> invocation
>> > until we have beta 3 next month.
>>
>> That's possibly dozens---if not hundreds---of CI setups that would
>> require a
>> temporary hack in order to be able to continue testing with Python 3.11.
>> It's
>> wonderful that they can and many already do that now. Wouldn't it be more
>> practical to bite the bullet and release b3 immediately with this fix?
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>>
>>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GGIM7LVOMMFE3O3E4MZKDZ55ESRAAWXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

[Pablo Galindo Salgado]

> Wouldn't it be more practical to bite the bullet and release b3
immediately with this fix?

I sympathize with the sentiment and I am sorry that this is not practical
but I am not fully convinced about the balance. Beta 3 is in one month and
spinning an entire release is a multi-hour process for at least 3 people. I
will discuss this with the release team but is unlikely. For testing at
fedora, you can temporarily patch beta2 and include this commit:

https://github.com/python/cpython/commit/b425d887aa51c8e7900b08cb8df457f450f6fbfd

On Wed, 1 Jun 2022 at 00:19, Miro Hrončok  wrote:

> On 01. 06. 22 0:02, Pablo Galindo Salgado wrote:
> > You may be able to work around this issue by preventing pytest to
> rewrite the
> > assert statements by adding `--assert=plain` to the command line
> invocation
> > until we have beta 3 next month.
>
> That's possibly dozens---if not hundreds---of CI setups that would require
> a
> temporary hack in order to be able to continue testing with Python 3.11.
> It's
> wonderful that they can and many already do that now. Wouldn't it be more
> practical to bite the bullet and release b3 immediately with this fix?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BPXKXH4IUYE2NNNCH5RSW67LQNG4KRQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

[Pablo Galindo Salgado]

I have added a small note in the release announcements. Thanks for raising
this with us!

On Wed, 1 Jun 2022 at 00:13, Jean Abou Samra  wrote:

>
>
> Le 01/06/2022 à 00:02, Pablo Galindo Salgado a écrit :
> > You may be able to work around this issue by preventing pytest to
> > rewrite the assert statements by adding `--assert=plain` to the
> > command line invocation until we have beta 3 next month.
>
> Thank you! That did the trick. Worth mentioning in those release
> announcements that are editable, perhaps.
>
> Best,
> Jean
>
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OY745TS4HOCXZ6LIFOUC7K7GCK2OOXJV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available

[Pablo Galindo Salgado]

You may be able to work around this issue by preventing pytest to rewrite
the assert statements by adding `--assert=plain` to the command line
invocation until we have beta 3 next month.

On Tue, 31 May 2022 at 23:57, Jean Abou Samra  wrote:

> Hi,
>
>
> Le 31/05/2022 à 15:31, Pablo Galindo Salgado a écrit :
> > 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.
>
>
> I just tried doing that on the project I help maintaining (Pygments),
> but it turns out that it's a bit hard, presumably for many projects
> too, due to
>
> https://github.com/pytest-dev/pytest/issues/10008
>
> which prevents pytest from running with 3.11.0b2.
>
> The fix for this issue is on the way (thanks!), but it has missed
> this release. Given pytest's popularity, this means 3.11.0b2 is
> sadly likely not to get as much testing exposure as wished ...
>
> Thus I wonder, would it be reasonable to exceptionally do another
> release shortly after this fix lands?
>
> Best,
> Jean
>
> PS: I tried to post this reply in Discourse, but apparently
> I'm not allowed to post in the category of the release
> announcement.
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JCYNNYN2SC45WBAS7DOLLFLUJHDEVK53/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht

[Python-Dev] Re: Is it possible to view tokenizer output?

[Pablo Galindo Salgado]

Is on the main branch but as I mentioned is **exclusively** for internal
consumption:

https://github.com/python/cpython/blob/8136606769661c103c46d142e52ec88803f6/Lib/tokenize.py#L685

On Mon, 30 May 2022 at 17:37, Jack  wrote:

> Hi Pablo, could you clarify please? Is that on the main branch, or would
> you be willing to share the code?
> On 30/05/2022 16:23, Pablo Galindo Salgado wrote:
>
> There is no *public* one but there is a private one accesible from Python
> I added for testing purposes.
>
> On Mon, 30 May 2022, 15:17 Victor Stinner,  wrote:
>
>> On Mon, May 30, 2022 at 1:40 AM Eric V. Smith  wrote:
>> > python -m tokenize < file-to-parse.py
>> >
>> > See the comment at the top of tokenize.py. IIRC, it re-implements the
>> > tokenizer, it does not call the one used for python code.
>>
>> Ah right, I would be surprised that there would be a public Python API
>> to get the tokenizer output, since there is no public C API for that
>> :-)
>>
>> I just removed  header file since it was never usable outside
>> Python C internals: there is no public C API to just run the tokenizer
>> and gets its output.
>>
>> Victor
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/CT3YSWSPMJ5DLUCVBX3AAPRWOUOXYWEL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UXPSZFOKCKGHUERUVO7UPLZK3L53CGFW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it possible to view tokenizer output?

[Pablo Galindo Salgado]

There is no *public* one but there is a private one accesible from Python I
added for testing purposes.

On Mon, 30 May 2022, 15:17 Victor Stinner,  wrote:

> On Mon, May 30, 2022 at 1:40 AM Eric V. Smith  wrote:
> > python -m tokenize < file-to-parse.py
> >
> > See the comment at the top of tokenize.py. IIRC, it re-implements the
> > tokenizer, it does not call the one used for python code.
>
> Ah right, I would be surprised that there would be a public Python API
> to get the tokenizer output, since there is no public C API for that
> :-)
>
> I just removed  header file since it was never usable outside
> Python C internals: there is no public C API to just run the tokenizer
> and gets its output.
>
> Victor
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CT3YSWSPMJ5DLUCVBX3AAPRWOUOXYWEL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5AWZ4NJCS5TVWMR2KZOWLJT7AYDCXVIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python grammar test cases

[Pablo Galindo Salgado]

That's used as a literal '/' to make positional-only arguments work. For
example:

lambda x, y, /, z: x+y+z

On Tue, 10 May 2022 at 17:11, Venkat Ramakrishnan <
venkat.archit...@gmail.com> wrote:

> I am looking at:
> https://docs.python.org/3/reference/grammar.html
>
> in which the following definition is found:
>
> lambda_slash_no_default:
> | lambda_param_no_default+ '/' ','
> | lambda_param_no_default+ '/' &':'
>
> Can someone tell me how '/' is being used here in the syntax?
>
> Thanks,
> Venkat.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/WNQVENTVABM5VIVUMEPR4WTOV7GMHFXS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OXIMIVB5AME7IBP6MBIGFVGH3Y5JMZKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python grammar test cases

[Pablo Galindo Salgado]

Could you share with us some of the context of what are you trying to
achieve? That way we can offer more specialized help :)

On Tue, 10 May 2022 at 15:50, Venkat Ramakrishnan <
venkat.archit...@gmail.com> wrote:

> Presuming I am looking at the right link?:
> https://github.com/python/cpython/tree/main/Lib/test
>
> I am currently focusing on Lambda function. I have a
> few test cases written. I have some questions too. Would
> be great if I could talk/chat to someone about these
> questions.
>
> Thanks.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LPIBWDUTRQZWQBU4RUEM6GTMA2XQIZMX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GBROHP7GTMWANA7UHDXTIVKI7M4MJEZI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python grammar test cases

[Pablo Galindo Salgado]

In addition, test_exceptions test a bunch of syntax errors and related
locations.

On Tue, 10 May 2022 at 06:41, Serhiy Storchaka  wrote:

> 10.05.22 08:10, Venkat Ramakrishnan пише:
> > I'm wondering if there's a repository of test cases that
> > test the Python grammar. Any help would be appreciated.
>
> See test_grammar and test_syntax. And there are some test files for
> specific grammar features, like test_string_literals, test_unpack_ex,
> test_genexps, test_fstring, etc.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/NW2D3WMQOOFVF5WHJDEG5B4TCIY7UR5U/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NWOU4BMUJYYGEDBGO4AWEAAVGUJKIJP7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here

[Pablo Galindo Salgado]

I have updated it a while ago but it may take some time for the CDN to drop
the cache. Thanks for heads up!

On Sun, 8 May 2022 at 19:08, Mats Wichmann  wrote:

> On 5/7/22 21:22, Pablo Galindo Salgado wrote:
>
> > 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://bugs.python.org <https://bugs.python.org>)
> > as soon as possible.
>
>
> Seems like this bit of the template needs an upgrade -> github?
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/QTCPBDR7UHZX4Z624TTITAMLOVOMLACQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CQMXENX73WHZY4VORRY4F6C7X6TG57F4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here

[Pablo Galindo Salgado]

Thanks for the heads up. Technically the links are not wrong, the problem
is that the closing ) is incorrectly part of the link in this mail (is
correct everywhere els), so it doesn't work. I will correct this in future
announcements.


On Sun, 8 May 2022 at 17:35, MRAB  wrote:

> On 2022-05-08 04:22, Pablo Galindo Salgado wrote:
> > We did it, team!! After quite a bumpy release process and a bunch of
> > last-time fixes, we have reached **beta 1** and **feature freeze**. What
> > a ride eh? You can get the shiny new release artefacts from here:
> >
> > https://www.python.org/downloads/release/python-3110b1/
> > <https://www.python.org/downloads/release/python-3110b1/>
> > ## This is a beta preview of Python  3.11
> >
> > Python 3.11 is still in development. 3.11.0b1 is the first 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://bugs.python.org <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.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
> >
> > Python 3.11 is still in development.  This release, 3.11.0b1 is the
> > **first** of four beta releases.
> > 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.
> >
> > 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
> > * [PEP 680](https://www.python.org/dev/peps/pep-0680/
> > <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/)
> > <https://www.python.org/dev/peps/pep-0675/)>-- Arbitrary Literal String
> Type
> > * [PEP 655](https://www.python.org/dev/peps/pep-0655/
> > <https://www.python.org/dev/peps/pep-0655/>)-- Marking individual
> > TypedDict items as required or potentially-missing
>
> FYI, 2 of these PEP links are missing/wrong:
>
> https://www.python.org/dev/peps/pep-0646/ (Variadic Generics) is at
> https://peps.python.org/pep-0646/
>
> https://www.python.org/dev/peps/pep-0675/ (Arbitrary Literal String
> Type) is at https://peps.python.org/pep-0675/
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/U3257YIGC5HLFXKPFBYX6VFJWSGRWBSU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HM65JRKZ4POBXMZSYGYUP4J5OHIRXS26/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here

[Pablo Galindo Salgado]

Done in all places that I can edit! Thanks for the catch :)

On Sun, 8 May 2022 at 09:14, Oleg Iarygin  wrote:

> - python-announce@, python-committers@, python-list@
>
> > report issues found to [the Python bug tracker](https://bugs.python.org)
> as soon as possible
>
> The template needs to be updated.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M7BTZNRV2LO32CIACNAAQQU67BMFDEMF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Pablo Galindo Salgado]

tropy 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7OR4SFLN4LLXQW3KHDHA6POAX5TBSTVM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/I2NI4VW33O5J5WI3UANJK2QNFWOQCQ4T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YQAE62CAEASIBGHQ5LQZKT3JZ4BVIYKJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Decreasing refcount for locals before popping frame

[Pablo Galindo Salgado]

As it has been mentioned there is no guarantee that your variable will even
be finalized (or even destroyed) after the frame finishes. For example, if
your variable goes into a reference cycle for whatever reason it may not be
cleared until a GC run happens (and in some situations it may not even be
cleared at any point). The language gives you no guarantees over when or
how objects will be finalized or destroyed and any attempt at relying on
specific behaviour is deemed to fail because it can change between versions
and implementations.



On Thu, 28 Apr 2022, 14:14 Malthe,  wrote:

> Consider this example code:
>
> def test():
> a = A()
>
> test()
>
> Currently, the locals (i.e. `a`) are cleared only after the function
> has returned:
>
> If we attach a finalizer to `a` immediately after the declaration then
> the frame stack available via `sys._getframe()` inside the finalizer
> function does not include the frame used to evaluate the function
> (i.e. with the code object of the `test` function).
>
> The nearest frame is that of the top-level module (where we make the
> call to the function).
>
> This is in practical terms no different than:
>
> def test():
> return A()
>
> test()
>
> There's no way to distinguish between the two cases even though in the
> second example, the object is dropped only after the frame (used to
> evaluate the function) has been cleared.
>
> The effect I am trying to achieve is:
>
> def test():
> a = A()
> del a
>
> Here's a use-case to motivate this need:
>
> In Airflow, we're considering introducing some "magic" to help users write:
>
> with DAG(...):
> # some code here
>
> That is, without declaring a top-level variable such as `dag`.
>
> However, we can't detect the following situation:
>
> def create():
> with DAG(...) as dag:
> # some code here
>
> create()
>
> The DAG is not returned from the function but nevertheless, we can't
> distinguish between this code and the correct version:
>
> def create():
> with DAG(...) as dag:
> # some code here
> return dag
>
> In this case, calling `create` will then "return" the DAG and of
> course, without a variable assignment, the finalizer will be called –
> but now we can detect this.
>
> I'm thinking that it ought to be possible to clear out
> `frame->localsplus` before leaving the function frame.
>
> I played around with "ceval.c" and only got segfaults. It's
> complicated machinery :-)
>
> Thoughts?
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/D5HCLMN42SIRRUHWPU566R7YYAVLCAEN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BUT34WUMBSQHKASHDTRSZI5H7GSUAX72/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Pablo Galindo Salgado]

That's an interesting idea but the objective is not to only produce a
backwards compatible version but also a maintainable solution that also
doesn't have weird side effects or strange behaviour. I find things that
behaves like that a bit surprising. But this is something we could
certainly do.

On Sun, 17 Apr 2022, 20:40 MRAB,  wrote:

> On 2022-04-17 18:20, Pablo Galindo Salgado wrote:
> > Hi,
> >
> > We are currently debating in gh-88116
> > (https://github.com/python/cpython/issues/88116
> > <https://github.com/python/cpython/issues/88116>)
> > what's the best way forward to update the APIs in the inspect module to
> > include the new position information.
> >
> > These APIs are inspect.getframeinfo, inspect.getouterframes,
> > inspect.getinnerframes, inspect.stack and inspect.trace.
> >
> > The problem is that these APIs return a named tuple that now needs to
> > include several new attributes (or one 4 tuple for
> > the positions). Being named tuples, if we add a new attribute, existing
> > unpackings of the tuple will now fail because there
> > are more elements or the elements are in different positions. Also, it
> > will be quite weird to add the new attributes at the
> > end but leave the line number at the beginning.
> >
> > What's the best way to proceed here? The suggested way is to create a
> > namedtuple subclass that adds the extra attributes
> > but doesn't allow indexed access to it (there is a precedent to this in
> > how we handled updating os.stat_result). I personally
> > find this quite confusing but it certainly works. There may be other
> > options.
> >
> > What do you think?
> >
> Why not allow indexed access to the extra attributes?
>
> You could return only the current attributes by default, but the extra
> attributes on demand. (Slightly strange, but backwards-compatible.)
> Slicing could also return what was requested, e.g. t[ : 4] would return
> the first 4, t[ : 5] the first 5, t[ : ] all of them, etc. (Again,
> strange, but backwards-compatible.)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/I7EX35AYMMXGH3N3KOCCPLAUYCHGISJP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IT6KQT6IWVFECHY3LKKAN6UCZIHFJWMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Updating inspect APIs

[Pablo Galindo Salgado]

Hi,

We are currently debating in gh-88116 (
https://github.com/python/cpython/issues/88116)
what's the best way forward to update the APIs in the inspect module to
include the new position information.

These APIs are inspect.getframeinfo, inspect.getouterframes,
inspect.getinnerframes, inspect.stack and inspect.trace.

The problem is that these APIs return a named tuple that now needs to
include several new attributes (or one 4 tuple for
the positions). Being named tuples, if we add a new attribute, existing
unpackings of the tuple will now fail because there
are more elements or the elements are in different positions. Also, it will
be quite weird to add the new attributes at the
end but leave the line number at the beginning.

What's the best way to proceed here? The suggested way is to create a
namedtuple subclass that adds the extra attributes
but doesn't allow indexed access to it (there is a precedent to this in how
we handled updating os.stat_result). I personally
find this quite confusing but it certainly works. There may be other
options.

What do you think?

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

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

[Pablo Galindo Salgado]

I will consider adding it, but I am not sure it qualifies as a "major
feature". I will think about it :)

On Wed, 6 Apr 2022 at 13:38, Jeremiah Vivian 
wrote:

> > Can you provide a bpo number, please?
> bpo-433030
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/M46P53HIT54YIJWJGE65P6CSWOBNDVYB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NIMY6CJBIFCQL4SZMTEF2VEOQ2CUGZDU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Pablo Galindo Salgado]

> This section of major new features should've included the addition of
atomic groups/possessive matching into the `re` module. This is a boost in
regex matching performance when the pattern doesn't need any backtracking.

Can you provide a bpo number, please?

On Wed, 6 Apr 2022 at 13:15, Jeremiah Vivian 
wrote:

> > Among the new major new features and changes so far:
> This section of major new features should've included the addition of
> atomic groups/possessive matching into the `re` module. This is a boost in
> regex matching performance when the pattern doesn't need any backtracking.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RQLG4LHKRALHERZKARFXUDTYCRBFV6ST/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TOPYFQCA67CJ6NRFT7BTUIQIVTCMDO6I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [IMPORTANT] Preparations for 3.11.0 beta 1

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NCAQXXV6MYP24V6WO4BUC4Y7BZK4FM7D/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 distribution 

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

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/L42CSIJJBZRDC5UTXI4BXBT2KQ2HHPCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Make HAMT available to python script

[Pablo Galindo Salgado]

You may want to check PEP 603, which more or less proposes this (the author
of the pep is the author of the HAMT code)
 check https://peps.python.org/pep-0603/

Alternatively, there is already a pypi package with this code:

https://pypi.org/project/immutables/

Regards from cloudy London,
Pablo

On Fri, 1 Apr 2022, 10:34 zhang kai,  wrote:

> Hi,
>
> HAMT is a very useful immutable mapping type. Currently CPython use it
> internally to implement contextvar. Considering immutable data structure is
> very useful I hope we can make it available to python script(maybe via
> collections module).
>
> Immutable data structures are fundamental parts of our project. Currently
> we use a full-featured python immutable data library called pyrsistent.
> Pyrsistent is very powerful, however the map type in it is implemented in
> python script not in C. It becomes slow when the data set is relatively
> large.
>
> On the other hand, CPython now already has an immutable mapping type in
> it. I think maybe it’s a good idea to make it public? Many projects can
> benefit from it I believe.
>
> Here is a talk given by the author of javascript immutable-js library
> explain why immutable data structures are powerful:
> https://www.youtube.com/watch?v=I7IdS-PbEgI
>
> Pyristent: https://github.com/tobgu/pyrsistent
>
> What do you think?
>
> Cheers,
> Kai
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2WYPX44WBFS2ZMZFNMDFMRPROB7G34JQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WSNGWKINHMVM2BWOO545FYEOSIXTZKOW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.10.4 and 3.9.12 are now available out of schedule

[Pablo Galindo Salgado]

The docs will be updated later today, but the sources are already here:

https://docs.python.org/release/3.10.4/whatsnew/changelog.html#python-3-10-4-final

On Thu, 24 Mar 2022 at 13:44, Damian Shaw 
wrote:

> I guess the docs aren't updated yet and the changes are listed as "Python
> Next": https://docs.python.org/3.10/whatsnew/changelog.html#changelog ?
>
> Damian(he/him)
>
> On Thu, Mar 24, 2022 at 8:13 AM Łukasz Langa  wrote:
>
>> Did anybody say cursed releases
>> <https://discuss.python.org/t/python-3-10-3-3-9-11-3-8-13-and-3-7-13-are-now-available-with-security-content/14353>?
>> Well, it turns out that 3.10.3 and 3.9.11 both shipped a regression which
>> caused those versions not to build on Red Hat Enterprise Linux 6. While
>> this 11-year-old version is now out of maintenance support
>> <https://access.redhat.com/support/policy/updates/errata>, it’s still
>> used in production workloads. Some of those rely on Python 3.9 and/or 3.10.
>> In particular, our own manylinux2010
>> <https://github.com/pypa/manylinux/tree/manylinux2010_x86_64_centos6_no_vsyscall>
>> image used to build widely compatible Linux wheels is based on CentOS 6.
>> (Don’t worry, we do have newer manylinux* variants, see PEP 599
>> <https://peps.python.org/pep-0599/> and PEP 600
>> <https://peps.python.org/pep-0600/> for details.)
>>
>> Due to the out-of-schedule release, the respective versions released
>> today contain a very limited set of changes. Python 3.9.12 only contains 12
>> other bug fixes on top of 3.9.11. Python 3.10.4 only contains 10 other bug
>> fixes on top of 3.10.3.
>>
>> Get 3.10.4 here: Python Release 3.10.4 | Python.org
>> <https://www.python.org/downloads/release/python-3104>
>> Get 3.9.12 here: Python Release 3.9.12 | Python.org
>> <https://www.python.org/downloads/release/python-3912>
>>
>> Hopefully, the third time’s a charm and we’ll return no sooner than May
>> with the regularly scheduled bug fix releases of 3.9 and 3.10.
>>
>> <https://discuss.python.org/t/python-3-10-4-and-3-9-12-are-now-available-out-of-schedule/14568#we-hope-you-enjoy-the-new-releases-1>We
>> hope you enjoy the new releases
>>
>> Your friendly release team,
>> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
>> Pablo Galindo Salgado @pablogsal <https://discuss.python.org/u/pablogsal>
>> Ned Deily @nad <https://discuss.python.org/u/nad>
>> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/SGB4B572RDPZ7SIJ5A6NZAI3Z3GKNIXA/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AHLDJISO2YFGXIZD3ON5F6QDPMVE3DD5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EXOYIWNOV6ZTFKBZUMNDDTMNTVZPF25T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Pablo Galindo Salgado]

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

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

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

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

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

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

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

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

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

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

# More resources

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

# And now for something completely different

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

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

# We hope you enjoy those new releases!

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

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

[Python-Dev] Re: Python 3.11.0a6 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HO62U6PSAAJTLBMN2PH7ZNXFJK5IXBRF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.11.0a6 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/L5HIYXRWAL7YPM7WIHBRFJ4GG4IVJ6LI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.11.0a6 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TJCBPZNLSWQU2OX63CTWS2SHEJQN6P37/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] October/November/December Steering Council update

[Pablo Galindo Salgado]

several aspects on how it has operated so far.
   - The SC received an updated from Thomas on the status on the search for
   a new PSF director.
   - The SC briefly reflected and discussed the diversity in the Steering
   Council and how to improve the situation in the future. This topic will be
   discussed further in the future.
   - The SC approved a request for a wording change in PEP 654 - Exception
   groups <https://www.python.org/dev/peps/pep-0654/>.
   - The SC had an overview of unresolved issues: definition/rules for the
   standard library, split in communication channels and the situation
   regarding type annotations with PEP 563 and 649.
   - The new SC decided to use discord as a new communication channel.
   - The SC discussed the status on the GitHub issues migration and what to
   do next to push the work forward.


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

[Python-Dev] Re: Custom memory profiler and PyTraceMalloc_Track

[Pablo Galindo Salgado]

>
> However, I still wonder: is there anyway to support `PyTraceMalloc_Track`
> API without being dependent to `tracemalloc`? I know there is not many
> memory tracing tools but I mean I still feel like there should be a generic
> way of doing this: A very vague example for demonstration:
>
> PyMemHooks_GetAllocators/PyMemHooks_SetAllocators/PyMemHooks_TrackAlloc
> which are public APIs and tracemalloc using them internally instead of
> allocator APIs?
>

This can be investigated, but this is equivalent to add tracing support to
the memory allocators and then make tracemalloc a client of such APIs.

This can be advantageous to tool authors but it can raise the maintenance
cost of the allocators as we would need to make these APIs generic enough
as different tools have different constraints (like having to hold the Gil
or not to call these APIs, what information can be passed down (do you want
to know the pointer and the kind of allocator it was used...etc). There are
even tools that want to link the allocated blocks to python objects
directly (which is not possible without a considerable redesign).

I would recommend opening an issue in bugs.python.org where this can be
discussed and (maybe) implemented. Please, feel free to add me to the issue
once open :)

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

[Python-Dev] Re: Custom memory profiler and PyTraceMalloc_Track

[Pablo Galindo Salgado]

The memory allocators don't have any context of tracing, they just
allocate. Tracemalloc is a trampoline based allocator that also trace
what's going on, bit from the point of view of the python allocator system
is just another allocator.

There is no concept of "notify the python allocator" because the python
allocator system doesn't have the concept of external allocation events.
You can override it entirely to do something extra, but it is designed (as
many other allocators) to not be aware of the existence of other systems
running in parallel. In other words, the allocators are concerned about
memory, not tracing or anything else that can be done by overriding them.

That's why there is no "notify allocator" APIs in the python allocators.

Regards from rainy London,
Pablo Galindo Salgado

On Tue, 15 Feb 2022, 13:57 Sümer Cip,  wrote:

> Hi everyone,
>
> I would like to ask a question about an issue that we faced regarding
> profiling memory usage:
>
> We have implemented a custom memory profiler using
> `PyMem_GetAllocator/PyMem_SetAllocator` APIs like `tracemalloc`. Right now,
> we are facing an issue with numpy: numpy seems to have its own memory
> allocator and they use `PyTraceMalloc_Track` APIs to notify tracemalloc
> about the allocation. A simple search on GitHub reveals there are more
> projects using this approach:
> https://github.com/search?q=PyTraceMalloc_Track=code which is fine.
> I believe it is common to use custom memory allocators for scientific
> computation which makes perfect sense.
>
> However, I would have expected to have at least some form of
> `PyMem_NotifyAllocator` type of API instead of a one that is specific to
> `tracemalloc`? I might be missing some context here.
>
> WDYT?
>
> Best,
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/BHOIDGRUWPM5WEOB3EIDPOJLDMU4WQ4F/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ATULLVYZMDGNOE2NYC53ZUZXBBAHLNSO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Pablo Galindo Salgado]

That is on pourpose and is the public API for Python. In Python it returns
an iterable of tuples,
which is processed from the actual internal form.

On Wed, 9 Feb 2022 at 18:56, Victor Stinner  wrote:

> On Wed, Feb 9, 2022 at 5:48 PM Pablo Galindo Salgado
>  wrote:
> > We consider the representation of co_postions private, so we don't want
> (for now) to ad
> > getters/setters. If you want to get the position of a instruction, you
> can use PyCode_Addr2Location
>
> The code.co_positions() method is accessible in Python: it's not
> documented, but its name doesn't say that it's private. Was it done on
> purpose? Should it renamed to _co_positions() or even be removed?
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MPQ2XT5HYTLCJ3DEH4EH7QP7BEZ57OCN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

[Pablo Galindo Salgado]

I can only say that currently, I am not confident to expose such an API,
at least for co_positions, as the internal implementation is very likely to
heavily change and we want to have the possibility of changing it between
patch versions if required (to address bugs and other things like that).

On Wed, 9 Feb 2022 at 17:38, Stefan Behnel  wrote:

> Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
> >> Should there be a getter/setter for co_positions?
> >
> > We consider the representation of co_postions private
>
> Yes, and that's the issue.
>
>
> > so we don't want (for now) to ad
> > getters/setters. If you want to get the position of a instruction, you
> can
> > use PyCode_Addr2Location
>
> What Cython needs is the other direction. How can we provide the current
> source position range for a given piece of code to an exception?
>
> As it stands, the way to do this is to copy the implementation details of
> CPython into Cython in order to let it expose the specific data structures
> that CPython uses for its internal representation of code positions.
>
> I would prefer using an API instead that allows exposing this mapping
> directly to CPython's traceback handling, rather than having to emulate
> byte code positions. While that would probably be quite doable, it's far
> from a nice interface for something that is not based on byte code.
>
> And that's not just a Cython issue. The same applies to Domain Specific
> Languages or other programming languages that integrate with Python and
> want to show users code positions for their source code.
>
> Stefan
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VQSWX6MFKIA3RYPSX7O6RTVC422LTJH4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P7SMK5ZGFAHZMLUKW4WZNNX47CONXIQS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Pablo Galindo Salgado]

> Should there be a getter/setter for co_positions?

We consider the representation of co_postions private, so we don't want
(for now) to ad
getters/setters. If you want to get the position of a instruction, you can
use PyCode_Addr2Location

On Wed, 9 Feb 2022 at 16:22, Petr Viktorin  wrote:

> On 04. 02. 22 15:23, Stefan Behnel wrote:
> > Petr Viktorin schrieb am 03.02.22 um 13:47:
> >> On 02. 02. 22 11:50, Stefan Behnel wrote:
> >>> Maybe we should advertise the two modes more. And make sure that both
> >>> work. There are certainly issues with the current state of the
> >>> "limited API" implementation, but that just needs work and testing.
> >>
> >> I wonder if it can it be renamed? "Limited API" has a specific meaning
> >> since PEP 384, and using it for the public API is adding to the
> >> general confusion in this area :(
> >
> > I was more referring to it as an *existing* compilation mode of Cython
> > that avoids the usage of CPython implementation details. The fact that
> > the implementation is incomplete just means that we spill over into
> > non-limited API code when no limited API is available for a certain
> > feature. That will usually be public API code, unless that is really not
> > available either.
> >
> > One recent example is the new error locations in tracebacks, where PEP
> > 657 explicitly lists the new "co_positions" field in code objects as an
> > implementation detail of CPython. If we want to implement this in
> > Cython, then there is no other way than to copy these implementation
> > details pretty verbatimly from CPython and to depend on them.
> >
> > https://www.python.org/dev/peps/pep-0657/
> >
> > In this specific case, we're lucky that this can be considered an
> > entirely optional feature that we can separately disable when users
> > request "public API" mode (let's call it that). Not sure if that's what
> > users want, though.
>
> Should there be a getter/setter for co_positions?
> I'm unfortunately not aware of what Cython needs from code objects, but
> it might be good to extend the API here.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XK4DMU7I35TKXYJRYQE4RGMLNNBPDTYN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N537EIZR4KIR6Z7G3J2PTYC26DPH3YNC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

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

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

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

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

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

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

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

[Python-Dev] Blocking the main branch due to too many buildbots failing

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HU2LH5MX44QZXZ36YS4SOG4ZUPT4E7QT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Pablo Galindo Salgado]

The code that computes the lines is already quite complex (to the point
that has to do some AST analysis and post-parsing) so I am quite worried to
introduce a lot of complexity in this area. I am fine doing something that
we can easily check for (spawns all the line) but I would be against having
to start doing even more analysis (especially for things that are not
AST-based).

Take into account that code that displays exceptions need to be very
resilient because it can be called in some tricky situations and validating
that all the code works correctly is very hard, and complex to maintain.

As I said, I think I would be supportive of considering adding a check for
the full line, but I think that adding more complexity here is quite
dangerous.

On Tue, 18 Jan 2022 at 21:49, Patrick Reader <_...@pxeger.com> wrote:

> On 18/01/2022 20:41, Pablo Galindo Salgado wrote:
>
> We cannot base the computation on a % because is possible that the
> location markers are relevant
> but the variables, function names or constructs are just very large. I
> think that the idea of "spawns
> the whole line" is sensible, though.
>
> On Tue, 18 Jan 2022 at 20:32, Steve Dower  wrote:
>
>>
>> Omitting the line of ^ where over x% (75%? 90%?) of characters on the
>> line would be marked would be fine by me.
>
> It would also need to take into account cases where a line contains an
> inline comment, which does not contribute to the code producing the error,
> but where all of the rest of the line (the code) is the source of the error
> and highlighting it is not useful
>
> # test.py:
>
> code_that_causes_an_error # a comment
>
> $ python3.11 test.py
>
> Traceback (most recent call last):
>   File "test.py", line 1, in 
> code_that_causes_an_error # a comment
> ^
> NameError: name 'code_that_causes_an_error' is not defined
>
> (the traceback shown is from a current `main` build)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/F4FSJY7OIPHAH5I6YBHCFI4DP3XLNUJW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/G2D723CIGLMRRYJ43CGTTDHWXMRGOFIN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Pablo Galindo Salgado]

We cannot base the computation on a % because is possible that the location
markers are relevant
but the variables, function names or constructs are just very large. I
think that the idea of "spawns
the whole line" is sensible, though.

On Tue, 18 Jan 2022 at 20:32, Steve Dower  wrote:

> On 1/18/2022 7:59 PM, Pablo Galindo Salgado wrote:
> > We considered using colours and other markers such as bold text, but
> > that opens a considerable can of worms with detecting in all systems and
> > configurations if that can be done. I have been told that some of these
> > situations are quite tricky and is not as easy as checking for tty
> support.
> >
> > If someone wants to contribute a way to detect reliably (in C) if the
> > terminal supports ANSI colours, I'm happy to consider switching to that
> > instead of the underlying.
>
> I'll save some time - no such mechanism exists on Windows. There's no
> reliable way to detect what's displaying console output, and while many
> now support ANSI colours, we can't be assured of it.
>
> Omitting the line of ^ where over x% (75%? 90%?) of characters on the
> line would be marked would be fine by me.
>
> Cheers,
> Steve
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DA7KDNGCWQXHQCFDJ3FNXMWTYPLPXOYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Pablo Galindo Salgado]

We considered using colours and other markers such as bold text, but that
opens a considerable can of worms with detecting in all systems and
configurations if that can be done. I have been told that some of these
situations are quite tricky and is not as easy as checking for tty support.

If someone wants to contribute a way to detect reliably (in C) if the
terminal supports ANSI colours, I'm happy to consider switching to that
instead of the underlying.

On Tue, 18 Jan 2022, 19:13 Ethan Furman,  wrote:

> On 1/18/22 10:43 AM, Mats Wichmann wrote:
>
>  > A thought - how about omitting the underline line if the
>  > to-be-underlined part would be the whole line?
>
> I would also like that change -- when the underlining is a portion of the
> whole it's quite useful, but when it's the
> whole line it's a lot of extra noise.
>
> In fact, if I can be permitted to dream for a moment, what would be really
> nice is using highlighting or bolding or some
> such and skipping the extra underline lines (where "underlining" means
> "extra line with pointy hats").
>
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JYC5D3L6QW7V3ZOWMTBLYIGUQ6UOMS2U/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PVQOEYH4JK5I4LP4JKREYC63R4CI2KML/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Status of Python 3.11.0a4

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RZ7EJU66R5J3IMVCPP43ICZ23SQZNCP5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 679 – Allow parentheses in assert statements

[Pablo Galindo Salgado]

Hi everyone,

I would like to start a discussion about a small PEP proposal to allow
parentheses in
assert statements to fix a common gotcha with assert statements.

Link to the PEP: https://www.python.org/dev/peps/pep-0679/

*Please, redirect all discussions to: *

https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003

as I will not be monitoring answers to this thread.

Thanks, everyone for your time!

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

[Python-Dev] Re: Python 3.11.0a4 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UCGWU4VTU6YM63CQKMBROVEYOGW6CKWR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.11.0a4 is blocked

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7OWGAL4UL5HNKKQFUGH6N6L4JDVPEN7R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About the new CFrame structure

[Pablo Galindo Salgado]

Hi Gabriele,

>> So this makes me wonder if it would make sense for CPython to ensure
frame objects are created in a contiguous block of memory (perhaps there
could be benefits from the locality of reference, although it's not obvious
to me why this would be the case at the moment).


That's already the case for 3.11: we currently allocate frames in a
continuous, per thread stack (it includes some of the frame memory and
arrays apart from the frames themselves).

Check this for more details:
https://github.com/python/cpython/pull/27077

Also, don't rely on this on any way or form as this code can and will
likely change a lot (even between patch versions if we found bugs).

Regards from rainy London,
Pablo Galindo Salgado



On Mon, 20 Dec 2021, 21:43 Gabriele,  wrote:

> Brandt, Guido, Pablo
>
> Many thanks for your helpful answers. Indeed I'm asking because I just
> finished working on some improvements to Austin and got back to looking
> into what was coming in order to add support for 3.11 (plus make use of
> some of the changes that I recently contributed, like
> PyThreadState.native_thread_id, Py_Version and code.co_qualname). Pablo's
> suggestion of waiting until 3.11 becomes more stable is a sensible one, but
> in the meantime I wanted to understand where the frame stack management is
> heading to at least have an idea of what's in store for Austin :). I'm very
> much satisfied by all the details in your replies as they answer all my
> questions, for now, so thanks a lot for that.
>
> A final thought: I have discussed some of the technical details of the
> recent improvements to Austin in a blog post (
> https://p403n1x87.github.io/increasing-austin-accuracy-with-a-dobule-heap-trick.html).
> My experiments seem to suggest that, the less sparse the frame objects are
> in memory, the more accurate tools like Austin can be. So this makes me
> wonder if it would make sense for CPython to ensure frame objects are
> created in a contiguous block of memory (perhaps there could be benefits
> from the locality of reference, although it's not obvious to me why this
> would be the case at the moment).
>
> Best,
> Gabriele
>
>
> On Mon, 20 Dec 2021 at 20:16, Pablo Galindo Salgado 
> wrote:
>
>> Hi Gabriele,
>>
>> In addition to what Guido and Brandt have already said, I can help to you
>> adapting Austin to 3.11 as I reviewed or authored some of these changes and
>> I have already been helping some projects do the relevant changes as well
>> as in my own tools.
>>
>> What you want to do si the following for unwinding:
>>
>> * Go from _PyRuntime -> PyThreadState -> CFrame -> current_frame
>>
>> This will lead you to s PyInterpreterFrame that you should use for
>> unwinding the entire thread stack. The difference is that cframe->previous
>> will skip you several frames as it points to the previous CFrame, but there
>> are a one to many relationships between CFrame and interpreter frames
>> because several python functions can now reuse the same evaluation loop.
>>
>> Also, I would recommend waiting until beta freeze to start adapting
>> anything as things can still massively change until then for 3.11.
>>
>> If you have any questions or you need help, feel free to ping me in
>> GitHub if you want.
>>
>> Regards from rainy London,
>> Pablo Galindo Salgado
>>
>>
>>
>> On Mon, 20 Dec 2021, 18:27 Gabriele,  wrote:
>>
>>> Hi there
>>>
>>> I hope you would indulge me in asking for some details about the new
>>> CFrame structure, even in the form of existing literature (e.g. PEP)
>>> where the idea behind it is explained.
>>>
>>> Also, I'd like to a quick question, if I may. There now appear to be
>>> two ways of unwinding the frame stack: either iterate over
>>> CFrame.previous, or the more traditional PyFrameObject.f_back. I
>>> suspect there are reasons why these are perhaps not actually
>>> equivalent, and indeed this is mainly what I'd like to read in the
>>> literature I've requested above.
>>>
>>> Cheers,
>>> Gabriele
>>>
>>> --
>>> "Egli è scritto in lingua matematica, e i caratteri son triangoli,
>>> cerchi, ed altre figure
>>> geometriche, senza i quali mezzi è impossibile a intenderne umanamente
>>> parola;
>>> senza questi è un aggirarsi vanamente per un oscuro laberinto."
>>>
>>> -- G. Galilei, Il saggiatore.
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.o

[Python-Dev] Re: About the new CFrame structure

[Pablo Galindo Salgado]

Hi Gabriele,

In addition to what Guido and Brandt have already said, I can help to you
adapting Austin to 3.11 as I reviewed or authored some of these changes and
I have already been helping some projects do the relevant changes as well
as in my own tools.

What you want to do si the following for unwinding:

* Go from _PyRuntime -> PyThreadState -> CFrame -> current_frame

This will lead you to s PyInterpreterFrame that you should use for
unwinding the entire thread stack. The difference is that cframe->previous
will skip you several frames as it points to the previous CFrame, but there
are a one to many relationships between CFrame and interpreter frames
because several python functions can now reuse the same evaluation loop.

Also, I would recommend waiting until beta freeze to start adapting
anything as things can still massively change until then for 3.11.

If you have any questions or you need help, feel free to ping me in GitHub
if you want.

Regards from rainy London,
Pablo Galindo Salgado



On Mon, 20 Dec 2021, 18:27 Gabriele,  wrote:

> Hi there
>
> I hope you would indulge me in asking for some details about the new
> CFrame structure, even in the form of existing literature (e.g. PEP)
> where the idea behind it is explained.
>
> Also, I'd like to a quick question, if I may. There now appear to be
> two ways of unwinding the frame stack: either iterate over
> CFrame.previous, or the more traditional PyFrameObject.f_back. I
> suspect there are reasons why these are perhaps not actually
> equivalent, and indeed this is mainly what I'd like to read in the
> literature I've requested above.
>
> Cheers,
> Gabriele
>
> --
> "Egli è scritto in lingua matematica, e i caratteri son triangoli,
> cerchi, ed altre figure
> geometriche, senza i quali mezzi è impossibile a intenderne umanamente
> parola;
> senza questi è un aggirarsi vanamente per un oscuro laberinto."
>
> -- G. Galilei, Il saggiatore.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/KQOQTLR5IXMJXYZGPDHWR32I2Z53UVBL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F4QZ3UXCW3ZLTUUKD3L4XFHHDWPZGJV4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

[Pablo Galindo Salgado]

>> It does seem a bit silly to actually be tracking that refcount :-)

Not that silly. It can easily help in C extensions to detect wrong DECREF
calls:

>> import ctypes
>> non = ctypes.c_long.from_address(id(None))
>> non.value = 10
>>
Fatal Python error: none_dealloc: deallocating None
Python runtime state: finalizing (tstate=0x55c66cf263f0)

Current thread 0x7f4afa383740 (most recent call first):
  
[1]635685 abort (core dumped)  python

On Thu, 16 Dec 2021 at 00:31, Christopher Barker 
wrote:

> On Wed, Dec 15, 2021 at 3:00 PM Guido van Rossum  wrote:
>
>
>> who cares if the refcount for None is 5000 or 1610612736? As long as the
>> refcount of *mortal* objects is the same as it was before, this shouldn't
>> be a problem.
>>
>
> indeed:
>
> $ python -c "import sys; print(sys.getrefcount(None))"
> 4110
>
> and a newly started iPython session:
>
> In [2]: sys.getrefcount(None)
> Out[2]: 28491
>
> It does seem a bit silly to actually be tracking that refcount :-)
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/36N4I4CJ53OR3CLDJSJUIXEAS3NIFURP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QNFHXI2IQYU7RDTUPMRITEPKNEXACQWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Pablo Galindo Salgado]

All singletons do, AFAIK. And most static types that I can think of also
do, even the empty tuple.

On Wed, 15 Dec 2021 at 16:49, Eric Snow  wrote:

> On Wed, Dec 15, 2021 at 2:50 AM Pablo Galindo Salgado
>  wrote:
> > One thing to consider: ideally, inmortal objects should not participate
> in the GC. There is nothing inheritly wrong if they do but we would need to
> update the GC (and therefore add more branching in possible hot paths) to
> deal with these as the algorithm requires the refcount to be exact to
> correctly compute the cycles.
>
> That's a good point.  Do static types and the global singletons
> already opt out of GC participation?
>
> -eric
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3EAUAU5PF5YEHW4XXAVQGSLF4QEFCMJ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Pablo Galindo Salgado]

One thing to consider: ideally, inmortal objects should not participate in
the GC. There is nothing inheritly wrong if they do but we would need to
update the GC (and therefore add more branching in possible hot paths) to
deal with these as the algorithm requires the refcount to be exact to
correctly compute the cycles.

On Wed, 15 Dec 2021, 09:43 Christian Heimes,  wrote:

> On 14/12/2021 19.19, Eric Snow wrote:
> > A while back I concluded that neither approach would work for us.  The
> > approach I had taken would have significant cache performance
> > penalties in a per-interpreter GIL world.  The approach that modifies
> > Py_INCREF() has a significant performance penalty due to the extra
> > branch on such a frequent operation.
>
> Would it be possible to write the Py_INCREF() and Py_DECREF() macros in
> a way that does not depend on branching? For example we could use the
> highest bit of the ref count as an immutable indicator and do something
> like
>
>  ob_refcnt += !(ob_refcnt >> 63)
>
> instead of
>
>  ob_refcnt++
>
> The code performs "ob_refcnt += 1" when the highest bit is not set and
> "ob_refcnt += 1" when the bit is set. I have neither tested if the
> approach actually works nor it's performance.
>
> Christian
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TBTHSOI2XRWRO6WQOLUW3X7S5DUXFAOV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GPZXLMYFNGEFPXHOG6W2MTAKU6MTEA7V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.11.0a3 is available

[Pablo Galindo Salgado]

Thanks, Mark for the catch! I have updated it in the release page and all
announcements where I can edit the text :)

On Thu, 9 Dec 2021 at 12:34, Mark Shannon  wrote:

>
>
> On 08/12/2021 11:51 pm, Pablo Galindo Salgado wrote:
>
> > * 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.
>
> Actually, it is quite a lot better than that at 19% on the standard
> benchmark suite :)
>
> https://gist.github.com/markshannon/0ddfb0b705d23b863477d7f7f9f00ef1
>
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/BDJFYAC5IL77MBYQMH56D7ST67GDBMN2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZHXCZTGL3RQN5TMALN6V6OCQEHZR32HZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

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

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

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!

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

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

[Python-Dev] [RELEASE] Python 3.10.1 is available

[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-dev@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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CFCZC5ZQFSQD3C32IKHO6SQSZHCWZTNC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Optimizing literal comparisons and contains

[Pablo Galindo Salgado]

I agree with Serhiy's analysis.

On Mon, 29 Nov 2021 at 17:10, Serhiy Storchaka  wrote:

> 29.11.21 18:36, Victor Stinner пише:
> > You should consider "no longer have to justify why it's not optimized"
> > as a clear benefit of making this change :-) This optimization is
> > proposed once a year for many years...
> >
> > For me, any possible compilation-ahead optimization (which doesn't
> > break the Python semantics) is worth it ;-) It's done once, possible
> > even before the program is run for the first time, and then makes the
> > code faster.
>
> I consider the cost of rejecting such idea (this is actually the first
> time it was pushed so persistent) less than the cost of implementing and
> maintaining it. The proposed PR adds around 200 lines of code. It is
> almost 20% of the current size of ast_opt.c, it is not small. And just
> at first look I see a flaw in it -- it will emit a BytesWarning when
> compare strings and bytes. After fixing this the size will grow even
> more. And there may be other issues with this code which will be found
> months later. Later, when we rewrite the optimizer or change the
> structure of AST we will need to update this code too, with possibility
> to introduce new bugs.
>
> On other hand, the benefit of this optimization is exact zero. It does
> not make code faster, because it optimizes the code not used in real
> programs.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LOIK6ZX43QHQSNWWUSE6YE3O5YBVGJOM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LSDOY5TLG3AEAPBGR7BAPI65LEMZ3QZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] September Steering Council update

[Pablo Galindo Salgado]

I’ve just published the September steering council update, also included
below:

https://github.com/python/steering-council/blob/main/updates/2021-09-steering-council-update.md

Just as a reminder, if you have any questions or concerns, feel free to
contact us or open an issue in the SC repo:
https://github.com/python/steering-council

*September 6*

- There was no SC meeting on September 6 as it was a USA/Canada holiday
(Labor Day).

*September 13*

- The Steering Council met with Łukasz, the Developer-in-Residence. The
group
  discussed dealing with review requests and folks not giving Łukasz enough
  time to review before things are merged.
- The group briefly discussed Ezio's progress as the PM for the GitHub
Issues
  migration and that the group would meet with Ezio on the 20th of Sept.
- The SC discussed the Exception Groups PEP & Nathaniel's counter-proposal.
The
  group decided that more time was needed so they will discuss this more at
  their Sept 20th meeting.

*September 20*

- The Steering Council met with Ezio and got an update on his progress with
the
  migration. The group and Ezio agreed that by Oct 1 the plan is to have a
test
  repo with a subset of issues in it for a small group to test and provide
  feedback on.
- The Steering Council discussed [PEP 654](
https://www.python.org/dev/peps/pep-0654/)(
  Exception Groups and except*) and after some extensive deliberation, the
  group decided to accept.
- Thomas sent out the notification.
- The Steering Council discussed [PEP 649](
https://www.python.org/dev/peps/pep-0649/)(
  Deferred Evaluation Of Annotations Using Descriptors) by Larry Hastings.
The
  group decided that we have to tie the typing language to the Python
language.
  The group discussed the potential of an informational PEP from the SC.
- Pablo informed the SC that there will be a release party on Twitch for
3.10
  co-organized with the people from the Python discord server.

*September 27*

- Steering Council met with the Developer-in-Residence for their every-
other-
  week check-in. The group discussed what Łukasz is working on, the status
of
  typing PEPs and CPython survey questions for the Python Developer Survey.
- The SC discussed [PEP 649](
https://www.python.org/dev/peps/pep-0649/)(Deferred
  Evaluation Of Annotations Using Descriptors) by Larry Hastings and
decided a
  broader discussion needed to happen with python-dev. The group is
inclined to
  accept 649 but there is no clear path on how to handle the transition so
community
  discussion is needed.

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

[Python-Dev] Re: Oh wow, this is really impressive

[Pablo Galindo Salgado]

I am glad you like it :)

I have been told that this is a very popular improvement. I promise to keep
looking for similar things in the future!

Regards from cloudy London,
Pablo Galindo Salgado

On Fri, 29 Oct 2021, 18:23 Steven D'Aprano,  wrote:

> I was using Python 3.10 and got this NameError when I mistyped a name:
>
> NameError: name 'KeyboardInterrupted' is not defined. Did you mean:
> 'KeyboardInterrupt'?
>
> It even works for attribute errors too.
>
> That's fantastic! This is a really amazing useability improvement, thank
> you everyone who was involved! I literally squeed :-)
>
> I just may spend a few days deliberately mistyping names in the REPL
> just to see this :-)
>
>
> --
> Steve
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2CUCVKZ44IYCW5QRV4CMVC7YDYBCJFYG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BNXWMJDHBSBLCAMIRM4WY7O2YWXCJR6V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] August Steering Council update

[Pablo Galindo Salgado]

I’ve just published the August steering council update, also included below:

https://github.com/python/steering-council/blob/main/updates/2021-08-steering-council-update.md

Just as a reminder, if you have any questions or concerns, feel free to
contact us or open an issue in the SC repo:
https://github.com/python/steering-council

*August 2*

- The Steering Council met with the Developer-in-Residence (Łukasz Langa)
to discuss progress. The group also discussed what the focus should be
going forward and that strategic approaches need to be considered for PRs
instead of individual reviews.
- The Steering Council and Ewa (current PSF Executive Director) discussed
the lack of progress on the GitHub migration project. The contractor will
be meeting with the SC and Ewa next week to discuss progress and a timeline
to wrap up the project by end of October 2021.
- Thomas has several todos that he will take care of this week and he will
also reach out to the [PEP 505](
https://www.python.org/dev/peps/pep-0505/)(None-aware operators) authors to
get a status update.

*August 9*
- The Steering Council had a meeting with the GitHub issues PM (Ezio
Melotti) to learn why there has been a long period of no progress and
advise what needs to be done next. The SC also discussed with Ezio a
deadline of Oct 31 to complete the migration.
- After the call, the SC had a debrief to review how we would proceed
and whether or not we wanted to search for alternative options to complete
the project.
- Ewa drafted an email to Ezio on the next steps for the SC to review. The
email has been sent and Ezio is working on the deliverables. Ewa and Ezio
also had a call with one of our GitHub reps on import tooling.

*August 16*

- The Steering Council met with the Developer-in-Residence, where they gave
an update on their work as well as an update on where the data analytics is
heading. The group also discussed typing annotations and how to approach
the existing PEPs and migration paths.
- The Steering Council decided Thomas would be sending the drafted note to
the author of [PEP 648](
https://www.python.org/dev/peps/pep-0648/)(Extensible customizations of the
interpreter at startup) on Aug 17.
- The group checked in on [PEP 649](
https://www.python.org/dev/peps/pep-0649/)(Deferred Evaluation Of
Annotations Using Descriptors) by Larry Hastings and after some
deliberation decided that a wider discussion is necessary on how these are
handled. Barry suggested a workgroup to analyze things and Pablo reminded
the SC to make sure that all relevant actors that need to be part of that
discussion are present.
- Carol is going to ping Nathaniel and give him until the end of August
to submit a counter-proposal to [PEP 654](
https://www.python.org/dev/peps/pep-0654/)(Exception Groups and except*).

*August 23*

- Ewa scheduled check-in with Ezio for August 30th. SC discussed the code
of conduct situation with M.S. and decided on a one-year ban.
- SC brought up October 2021 sprints. They will be virtual. The group
will continue discussing.

*August 23*

- The Steering Council met with the Developer-in-Residence to discuss
progress and obstacles. They also discussed the CLA workflow and that
Łukasz will communicate with Yury as they were building something similar
for EdgeDB.
- The Steering Council met with Ezio to discuss his progress with the
GitHub migration project. The SC advised Ezio as to what the priority
projects are.

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

[Python-Dev] Re: Python multithreading without the GIL

[Pablo Galindo Salgado]

As far as I understand we should get a smaller improvement on single thread
because some of the optimizations listed in this work are partially or
totally implemented.

This is excluding any non linear behaviour between the different
optimizations of course, and assuming that both versions yield the same
numbers.

On Mon, 11 Oct 2021, 20:28 Abdur-Rahmaan Janhangeer, 
wrote:

> When you mean "an order of magnitude less overhead than the current
> CPython implementation" do you mean compared with the main branch? We
> recently implemented already almost everything is listed in this paragraph:
>
> https://github.com/python/cpython/pull/27077
>
> We also pack some extra similar optimizations in this other PR, including
> stealing the frame arguments from python to python calls:
>
> https://github.com/python/cpython/pull/28488
>
> This could explain why the performance is closer to the current master
> branch as you indicate:
>
>
> This means that if we remove the GIL + add the 3.11 improvements we should
> get some more speed?
>
> (or if those are integrated in the POC?)
>
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MSNUMB5L3KS55HHAEMQZLFOM6JL3RL2B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python multithreading without the GIL

[Pablo Galindo Salgado]

>
> To speed-up function calls, the interpreter uses a linear, resizable stack
> to store function call frames, an idea taken from LuaJIT. The stack stores
> the interpreter registers (local variables + space for temporaries) plus
> some extra information per-function call. This avoids the need for
> allocating PyFrameObjects for each call. For compatibility, the
> PyFrameObject type still exists, but they are created lazily as-needed
> (such as for exception handling and for sys._getframe).

The optimized function calls have about an order of magnitude less overhead
> than the current CPython implementation.

The change also simplifies the use of deferred reference counting with the
> data that is stored per-call like the function object. The interpreter can
> usually avoid incrementing the reference count of the function object
> during a call. Like other objects on the stack, a borrowed reference to the
> function is indicated by setting the least-significant-bit.


Congrats Sam! This is incredible work! One quick question after reading the
design doc:

When you mean "an order of magnitude less overhead than the current CPython
implementation" do you mean compared with the main branch? We recently
implemented already almost everything is listed in this paragraph:

https://github.com/python/cpython/pull/27077

We also pack some extra similar optimizations in this other PR, including
stealing the frame arguments from python to python calls:

https://github.com/python/cpython/pull/28488

This could explain why the performance is closer to the current master
branch as you indicate:

 It gets about the same average performance as the “main” branch of CPython
> 3.11 as of early September 2021.


Cheers from cloudy London,
Pablo Galindo Salgado

On Fri, 8 Oct 2021 at 03:49, Sam Gross  wrote:

> Hi,
>
> I've been working on changes to CPython to allow it to run without the
> global interpreter lock. I'd like to share a working proof-of-concept that
> can run without the GIL. The proof-of-concept involves substantial changes
> to CPython internals, but relatively few changes to the C-API. It is
> compatible with many C extensions: extensions must be rebuilt, but usually
> require small or no modifications to source code. I've built compatible
> versions of packages from the scientific Python ecosystem, and they are
> installable through the bundled "pip".
>
> Source code:
> https://github.com/colesbury/nogil
>
> Design overview:
>
> https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit
>
> My goal with the proof-of-concept is to demonstrate that removing the GIL
> is feasible and worthwhile, and that the technical ideas of the project
> could serve as a basis of such an effort.
>
> I'd like to start a discussion about these ideas and gauge the community's
> interest in this approach to removing the GIL.
>
> Regards,
> Sam Gross
> colesb...@gmail.com / sgr...@fb.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/K4SHFGDVAZUMAAKX5ZANAQIVYBPUSLEI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

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  – 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T4YIZDQWU23RQVPWAINIHUDBPGR7N3YQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[Pablo Galindo Salgado]

Just my two small cents: soft keywords have a cost as they make everything
around them more complicated in
the parser. For example, creating custom error messages around soft
keywords is one or two levels of magnitude
more complicated as sometimes you need to parse segments of
syntactically invalid code, with some generality
(like "starts with this token and then anything can follow until this other
token"). Soft keywords also make
highlighters' life more complicated as it has already been discussed.

And just to be clear: I am not saying they are bad, just that they are not
free of cost.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EADN7QLDNPRF7WRSTGAQ5QGS5WNDDBQQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Thanks for your work in Python 3.10

[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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YIZ4XLYW25UA3UVQLQHHIEYUK77ZE5XE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.10.0 is available

[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-dev@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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OQWNWZWDPASOUOAT6VPUXIXBH2THYREC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.10 release party

[Pablo Galindo Salgado]

Hi,

As it seems that I didn't have enough work dealing with the multiple
release blockers that have been raised these weeks I am also preparing a
Python 3.10 release party.

We will be doing an stream, co-hosted by the good people of Python discord
channel. The URL for the stream is this one:

https://youtu.be/AHT2l3hcIJg

The release party will start on October 4th at 17:00 UTC+0.

In this stream, some core developers (Irit, Carol, Brandt and Łukasz) will
be talking about Python 3.10 features and some sneak peak on Python 3.11
and beyond, talking about the core Dev in residence role and other things
with some time for moderated Q I will be doing the release live and will
also cover what I am doing. Is a fantastic opportunity to watch me make
mistakes live :)

The main purpose of the stream is to raise excitement about Python 3.10,
explain the new features to users, trying to get the community closer to
the core Dev team and allowing them to meet some of the new core Devs
(Brandt and Irit). Also, funny party hats will be used!

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

Please, reach out to me if you have any question or suggestion.

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

[Python-Dev] Re: The Default for python -X frozen_modules.

[Pablo Galindo Salgado]

> What is the annoyance? What is different between frozen and not frozen?

One interesting consequence of what Eric mentioned (They have a different
loader and repr.  Also, frozen modules do not
have __file__ set (and __path__ is always []).) is that frozen modules
don't have a `__file__` attribute IIRC and therefore
 tracebacks won't include the source.


On Mon, 27 Sept 2021 at 22:31, Victor Stinner  wrote:

> Hi Eric,
>
> Which stdlib modules are currently frozen? If I really want to hack
> site.py or os.py for whatever reason, I just have to use "python3 -X
> frozen_modules=off"?
>
> > 1. always default to "on" (the annoyance for contributors isn't big
> enough?)
>
> What is the annoyance? What is different between frozen and not frozen?
>
> Victor
>
> On Mon, Sep 27, 2021 at 6:58 PM Eric Snow 
> wrote:
> >
> > We've frozen most of the stdlib modules imported during "python -c
> > pass" [1][2], to make startup a bit faster.  Import of those modules
> > is controlled by "-X frozen_modules=[on|off]".  Currently it defaults
> > to "off" but we'd like to default to "on".  The blocker is the impact
> > on contributors.  I expect many will make changes to a stdlib module
> > and then puzzle over why those changes aren't getting used.  That's an
> > annoyance we can avoid, which is the point of this thread.
> >
> > Possible solutions:
> >
> > 1. always default to "on" (the annoyance for contributors isn't big
> enough?)
> > 2. default to "on" if it's a PGO build (and "off" otherwise)
> > 3. default to "on" unless running from the source tree
> >
> > Thoughts?
> >
> > -eric
> >
> >
> > [1] https://bugs.python.org/issue45020
> > [2] FWIW, we may end up also freezing the modules imported for "python
> > -m ...", along with some other commonly used modules (like argparse).
> > That is a separate discussion.
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4ESW3NNOX43DRFKLEW3IMDXDKPDMNRGR/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CLODS7B5Z3UEZTQ7QIALG2DWB4H37EWP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TDPS44OPEXK7MX3U2PMKTYLXNMQMA3MB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Porting python.gram to Python

[Pablo Galindo Salgado]

Hi Erik,

My first question is whether anyone is working on this as well (or
> hasalready done so and I missed it), to avoid duplication of effort.


We have already done this work. This was a contribution by Matthieu
Dartiailh:

https://github.com/we-like-parsers/pegen/blob/main/data/python.gram

I hope you find this useful,

Cheers from cloudy London,
Pablo


On Thu, 23 Sept 2021 at 20:10, Erik Demaine  wrote:

> Dear python-dev,
>
> I've been working on a port of cpython/Grammar/python.gram from C (as
> currently used in all the {} expressions to build the AST) to Python,
> directly
> building nodes via the ast package.  My motivation for this (as opposed to
> calling ast.parse, which uses the C parser) is to make it easy to
> experiment
> with adding features to the syntax, without having to build CPython.
> Porting
> is mostly straightforward, but it is a fair amount of work, because there
> are
> a lot of expressions to port
>
> My first question is whether anyone is working on this as well (or has
> already done so and I missed it), to avoid duplication of effort.
>
> Assuming not, my next question is where this belongs.  Some natural
> options I
> see:
>
> 1. Add it to cpython as a grammar maintained in parallel with the C
> grammar.
> This would mean more maintenance when the grammar changes, but the plus
> side
> is it guarantees that the two grammars (and ast) remain synchronized.
>
> 2. PyPy
>
> 3. 3rd party library (e.g., my own repo)
>
> Let me know what you think would be best.
>
> Erik
> --
> Erik Demaine  |  edema...@mit.edu  |  http://erikdemaine.org/
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/UM7ANICTBDU3Q2DLKFZIK6C6OU3THKP4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VN7HT3O4ZX6GEVUE4SGNRVU6WYZCLUG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Pablo Galindo Salgado]

>> What do you envision tokenize.py will do with f-strings after this?

It will emit new tokens: FSTRING_START FSTRING_MIDDLE '{' NAME
FSTRING_FORMAT '}' FSTRING_END


On Tue, 21 Sept 2021 at 12:50, Anders Munch  wrote:

> Pablo Galindo Salgado [mailto:pablog...@gmail.com]  wrote:
> > We already expose APIs that return AST objects that can be used for all
> sort of things and a tokenizer module that exposes some form of lexing that
> is relatively close to the one that CPython uses internally.
>
> What do you envision tokenize.py will do with f-strings after this?
> What would be the output of, say,
> $ echo 'f"hello {world!r}."' | python3 -m tokenize
> ?
>
> regards, Anders
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XXHWMINTPOLHLECS7BSHZPOC7RRN47T2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MQ56O3OW6H535667CAX54WZAMAWNBSTT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Pablo Galindo Salgado]

>> But I also think this means we definitely have to get a parser module

What is in this context a "parse" module? Because that will massively
change depending who you ask. We already expose APIs that return AST
objects that can be used for all sort of things and a tokenizer module that
exposes some form of lexing that is relatively close to the one that
CPython uses internally. The only missing piece would be something that
returns a CST with enough information to reconstruct the source but at this
point that is absolutely arbitrary because nothing in CPython would use
that tree. Not only that, but the requirements from such CST will change
quite a lot depending on who you ask and that impacts a lot the APIs that
we would need to offer.

Offering a parse module here can involve quite a high maintainance cost
without the certainly that will be useful to all set of users.

That also without considering that many tools parsing Python code are not
written on Python and will not be able to leverage it.

On Mon, 20 Sep 2021, 22:39 Brett Cannon,  wrote:

>
>
> On Mon, Sep 20, 2021 at 8:58 AM Thomas Grainger  wrote:
>
>> I don't think the python syntax should be beholden to syntax highlighting
>> tools, eventually some syntax feature that PEG enables will require every
>> parser or highlighter to switch to a similar or more powerful parse tool
>>
>
> But that's not how syntax highlighting works in editors. You typically
> don't get to choose the parsing tool used for syntax highlighting, you just
> define the grammar using whatever is provided by the editor (which has
> always been regexes based on my experience). So there's no way to "require"
> every editor out there to switch to a PEG parser or equivalent to support
> Python's grammar because that's asking every editor to change how syntax
> highlighting is implemented at a lower level.
>
> Having said all that, I think as long as we understand that this is a
> side-effect then it's fine; syntax highlighting is usually not tied to
> semantics in an editor so it shouldn't be a blocker on this. If people care
> they simply won't use the same type of quotes in their code (which I bet is
> what most people will do unless Black says otherwise ).
>
> But I also think this means we definitely have to get a parser module for
> tools together as this is way more potential breakage than just parentheses
> for `with` statements and I don't know if formatting tools can just move to
> the AST module at that point. 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/I4POAK22LZW4RNFGFFKQ6BILRLCSQO2I/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JCGJIU6ZHH4LLSL666EP2GBLMEJDVIOL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Pablo Galindo Salgado]

Thanks a lot, Eric for your message! I actually share some of these worries
myself
and that's why I wanted to have a bigger conversation.

I wanted to also make clear that the change doesn't force us to do
*everything*. This means
that we can absolutely have some of the improvements but not others (for
example allowing
backslashes but not nesting). So is important to be clear that is not "all
or nothing". We just need to
decide what set of things in the design space we want :)

On Mon, 20 Sept 2021 at 16:52, Eric V. Smith  wrote:

> On 9/20/2021 11:19 AM, Terry Reedy wrote:
> > On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote:
> >
> >> there are some interesting things we **could** (emphasis on could)
> >> get out of this and I wanted
> >> to discuss what people think about them.
> >>
> >> * The parser will allow nesting quote characters. This means that we
> >> **could** allow reusing the same quote type in nested expressions
> >> like this:
> >>
> >> f"some text { my_dict["string1"] } more text"
> >
> > I believe that this will disable regex-based processing, such as
> > syntax highlighters, as in IDLE.  I also think that it will be
> > sometimes confusing to human readers.
>
> When I initially wrote f-strings, it was an explicit design goal to be
> just like existing strings, but with a new prefix. That's why there are
> all of the machinations in the parser for scanning within f-strings: the
> parser had already done its duty, so there needed to be a separate stage
> to decode inside the f-strings. Since they look just like regular
> strings, most tools could add the lowest possible level of support just
> by adding 'f' to existing prefixes they support: 'r', 'b', 'u'. The
> upside is that if you don't care about what's inside an f-string, your
> work is done.
>
> I definitely share your concern about making f-strings more complicated
> to parse for tool vendors: basically all editors, alternative
> implementations, etc.: really anyone who parses python source code. But
> maybe we've already crossed this bridge with the PEG parser. Although I
> realize there's a difference between lexing and parsing. While the PEG
> parser just makes parsing more complicated, this change would make what
> was lexing into a more sophisticated parsing problem.
>
> In 2018 or 2019 at PyCon in Cleveland I talked to several tool vendors.
> It's been so long ago that I don't remember who, but I'm pretty sure it
> was PyCharm and 2 or 3 other editors. All of them supported making this
> change, even understanding the complications it would cause them. I
> don't recall if I talked to anyone who maintains an alternative
> implementation, but we should probably discuss it with MicroPython,
> Cython, PyPy, etc., and understand where they stand on it.
>
> In general I'm supportive of this change, because as Pablo points out
> there are definite benefits. But I think if we do accept it we should
> understand what sort of burden we're putting on tool and implementation
> authors. It would probably be a good idea to discuss it at the upcoming
> dev sprints.
>
> Eric
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DN5HB7CBS7I2FXI74UBM4ZZVMSNVDQ57/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YQU26OGHOTMJHCEO47YOUNEFGLWQ5DCG/
Code of Conduct: http://python.org/psf/codeofconduct/