[Python-Dev] [RELEASE] Python 3.8.4 is now available

2020-07-13 Thread Łukasz Langa
Python 3.8.4 is the fourth maintenance release of Python 3.8. Go get it here: https://www.python.org/downloads/release/python-384/ Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.5 planned for

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Guido van Rossum
On Mon, Jul 13, 2020 at 10:07 Federico Salerno wrote: > On 13/07/2020 12:28, Henk-Jaap Wagenaar wrote: > > No, that would not be impossible but fraught with problems. This is > discussed in the PEP: > > https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names > > The PEP goe

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Federico Salerno
On 13/07/2020 12:28, Henk-Jaap Wagenaar wrote: No, that would not be impossible but fraught with problems. This is discussed in the PEP: https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names The PEP goes into no detail of what these problems (or "number of subtleties"

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Rhodri James
On 13/07/2020 15:33, Guido van Rossum wrote: On Mon, Jul 13, 2020 at 04:35 Rhodri James wrote: [Re: forbidding **_ in mapping patterns] I’d rather not. And the argument about disallowing obviously redundant syntax seems weak. My worry about allowing this is that it’ll be cargo culled and

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Guido van Rossum
On Mon, Jul 13, 2020 at 04:35 Rhodri James wrote: > On 12/07/2020 23:20, Guido van Rossum wrote: > > So can we please lay this one to rest? > > Sure. One small thing before we leave it; I've decided I don't care > about the special cases of not using _. to lead class names, but > forbidding **_

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Rhodri James
On 12/07/2020 23:20, Guido van Rossum wrote: So can we please lay this one to rest? Sure. One small thing before we leave it; I've decided I don't care about the special cases of not using _. to lead class names, but forbidding **_ in mapping patterns seems unnecessary. I know it's redunda

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Henk-Jaap Wagenaar
On Mon, 13 Jul 2020 at 09:30, Federico Salerno wrote: > On 13/07/2020 00:20, Guido van Rossum wrote: > > The need for a wildcard pattern has already been explained -- we really > want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _, > _)`. Generating code to assign the value

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Federico Salerno
On 13/07/2020 00:20, Guido van Rossum wrote: The need for a wildcard pattern has already been explained -- we really want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _, _)`. Generating code to assign the value to `_` seems odd given the clear intent to *ignore* the value.

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-13 Thread Stephen J. Turnbull
Guido van Rossum writes: > [several reasons why not binding _ is a no-op, and] > A note about i18n: [...]. So can we please lay this one to rest? Yes, please! I was just about to ask about that. I could not believe that in July 2020 people were ignoring I18N, especially the fact that I18N w