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

[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 workers are mostly language specialists, not programmers, and are
quite dependent on programmers and UI/UX workers following "the usual
conventions".

Yes, mostly the message catalogs are produced by software that can be
taught to understand other conventions.  But often translators *do*
need to read source to get context for the (usually) English "key"
into the message catalogs.

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

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

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


Would it be impossible for the parser to interpret Point(x, y, y) as 
"the second and third arguments of Point must have the same value in 
order to match. Bind that value to y"? Since the value has to be the 
same, it doesn't matter whether y binds to the first or the second (or 
the nth) instance of it.


That said, in time and with all the arguments brought to the table, I 
personally came to accept special-casing _, although I don't especially 
like it. From my point of view, the biggest issue to solve is the load 
vs. store decision and its syntax.


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

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

[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 to `_` seems odd given the clear
> intent to *ignore* the value.
>
> Would it be impossible for the parser to interpret Point(x, y, y) as "the
> second and third arguments of Point must have the same value in order to
> match. Bind that value to y"? Since the value has to be the same, it
> doesn't matter whether y binds to the first or the second (or the nth)
> instance of it.
>
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
___
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/RQYFJ2TY3FLYLD233AH7VSQDOJRE7UQS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 
redundant, but I can imagine using it for emphasis.  I can't think of 
anywhere else the language forbids something just because it isn't 
needed, though I didn't get a lot of sleep last night and I could well 
be missing something obvious :-)


Can I use pattern matching to pull byte strings apart?  I thought I 
could, but trying it out in the playground didn't work at all. :-(


--
Rhodri James *-* Kynesim Ltd
___
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/WD2E3K5TWR4E6PZBM4TKGHTJ7VDERTDG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 **_ in mapping patterns seems unnecessary.  I know it's
> redundant, but I can imagine using it for emphasis.  I can't think of
> anywhere else the language forbids something just because it isn't
> needed, though I didn't get a lot of sleep last night and I could well
> be missing something obvious :-)


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 we’ll see it used not for emphasis (of what? The obvious?) but
because people think it’s needed. And that’s just clutter.


Can I use pattern matching to pull byte strings apart?  I thought I
> could, but trying it out in the playground didn't work at all. :-(


It’s explicitly forbidden by the PEP, because we don’t want str or bytes to
accidentally match sequence patterns. You could do ‘match list(b):’ if you
really wanted to, but I think there are better tools for parsing bytes or
strings.

—Guido

-- 
--Guido (mobile)
___
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/GQZGTCL4TTPTXPN3FRGOMNNC63YKBYQK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 we’ll see it used not for emphasis (of what? The obvious?) but
because people think it’s needed. And that’s just clutter.


Fair enough.  I'd likely use it to remind myself of cases when there 
will always be more keys in the mapping, but a comment will do just as well.



Can I use pattern matching to pull byte strings apart?  I thought I
could, but trying it out in the playground didn't work at all. :-(



It’s explicitly forbidden by the PEP, because we don’t want str or bytes to
accidentally match sequence patterns. You could do ‘match list(b):’ if you
really wanted to, but I think there are better tools for parsing bytes or
strings.


:-(  As an embedded engineer, pulling apart network protocols was the 
first use I thought of for matching.  Ah well.


--
Rhodri James *-* Kynesim Ltd
___
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/FDWO3SN3FTKUOMYCO3HRYDCPWMBGBM4P/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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") are, but it does mention how


we decided to make repeated use of names within the same pattern an 
error; we can always relax this restriction later without affecting 
backwards compatibility
which does hint at the fact that the problems are not insurmountable 
hurdles.


All in all not an urgent feature, but it would be nice to have from the 
get-go if there is agreement and it is doable.



@PEP authors: Incidentally, I am eager to start contributing and see 
this PEP advance—if there's anything I can do, including possibly 
non-code "dirty work" please let me know.
I was thinking of collecting all the objections and points of contention 
of the PEP and the current progress on each in one place so that the 
pros and cons can be evaluated more clearly. Would that be useful?


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

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

[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 goes into no detail of what these problems (or "number of
> subtleties") are, but it does mention how
>
> we decided to make repeated use of names within the same pattern an error;
> we can always relax this restriction later without affecting backwards
> compatibility
>
> which does hint at the fact that the problems are not insurmountable
> hurdles.
>
> All in all not an urgent feature, but it would be nice to have from the
> get-go if there is agreement and it is doable.
>
>
I find it debatable that we should have this at all, since there are other
interpretations possible, and honestly I doubt that it’s a common use case.
That’s why we’re holding off.

>
> @PEP authors: Incidentally, I am eager to start contributing and see this
> PEP advance—if there's anything I can do, including possibly non-code
> "dirty work" please let me know.
> I was thinking of collecting all the objections and points of contention
> of the PEP and the current progress on each in one place so that the pros
> and cons can be evaluated more clearly. Would that be useful?
>

Thanks for offering, but we’ve got that under control.

—Guido

> --
--Guido (mobile)
___
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/2CL4E7MIOXQFL2E76VP66QLIKWSHZC4U/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ł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 mid-September 2020.

What’s new?

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. See the “What’s New in Python 
3.8 ” document for more 
information about features included in the 3.8 series.

This is the first bugfix release that is considerably smaller than the previous 
three. There’s almost 20% fewer changes at 162 commits than the average of 
previous three bugfix releases. Detailed information about all changes made in 
version 3.8.4 specifically can be found in its change log 
.
 Note that compared to 3.8.3, version 3.8.4 also contains the changes 
introduced in 3.8.4rc1.

We hope you enjoy Python 3.8!

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,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv ___
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/JV6BY6UJTMRGS5WL2VH3ZNPCVESZAINZ/
Code of Conduct: http://python.org/psf/codeofconduct/