[Python-Dev] Re: What's up with assignment expression and tuples?
Hello,
On Sun, 7 Feb 2021 13:10:55 -0800
Guido van Rossum wrote:
> Hi Paul,
>
> I suggest that you just go straight to the PEP phase.
Thanks. In all fairness, I don't expect immediate resolution to this
issue. But I'm aware of out for at least a year, and keep returning to
it (yes, in context of my SSA experiments). So, I proceeded to the next
stage - bring it up on its own, then created a bug ticket:
https://bugs.python.org/issue43143
And my idea is to try to argue that it would be just a "grammar
bugfix", similarly to already existing grammar elaborations for walrus:
https://bugs.python.org/issue42316
https://bugs.python.org/issue42374
https://bugs.python.org/issue42381
Granted, allowing "foo((a, b) := (b, a))" is a bit bigger change than
allowing "foo[a := b]" instead of "foo[(a := b)]". But if people
find assigning within index expression useful, up to reporting it, and
then other people ack it and fix it, then why not fix parallel
assignment case? Implementation-wise they *seem* to be of the
similar effort/complexity - just a one-term grammar change. (I still
need to run the testsuite, yeah).
>
> --Guido
>
> On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky
> wrote:
>
> > Hello,
> >
> > Everyone knows how hard to find a compelling usecase for the
> > assignment expression operator (":=", colloquially "walrus
> > operator"). https://www.python.org/dev/peps/pep-0572/ examples
> > never felt compelling and we all remember the split it caused.
> >
> > I finally found a usecase where *not* using assignment expression is
> > *much* worse than using it. I'm working on SSA (Static Single
> > Assignment,
> > https://en.wikipedia.org/wiki/Static_single_assignment_form)
> > conversion of Python programs, where there's a need to "join"
> > dataflow of values from different control flow paths using a
> > special function (Phi function). This "joining" itself creates a
> > new variable, and of course, the original variable was used in an
> > expression. We've got assignment in expression, assignment
> > expression operator to the rescue!
> >
> > With it, a simple loop like:
> >
> >
> > a = 0
> > while a < 5:
> > a += 1
> >
> >
> > becomes:
> >
> >
> > a0 = 0
> > while (a1 := phi(a0, a2)) < 5:
> > a2 = a1 + 1
> >
> >
> > So far, so good. But semantics of Phi function is parallel
> > assignment. No problem with Python either, "a, b = b, c" is exactly
> > parallel assignment. So, let's try example with 2 variables:
> >
> >
> > a = 0
> > b = 10
> > while a < 5:
> > a += 1
> > b += 1
> >
> >
> > becomes:
> >
> >
> > a0 = 0
> > b0 = 10
> > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > a2 = a1 + 1
> > b2 = b1 + 1
> >
> >
> > But oops:
> >
> > > SyntaxError: cannot use assignment expressions with tuple
> >
> > To reproduce in the REPL:
> >
> >
> > >>> ((a, b) := (1, 2))
> > File "", line 1
> > SyntaxError: cannot use assignment expressions with tuple
> >
> >
> > Why this accidental syntactic gap? Why assignment statement can do
> > parallel assignment with a tuple on LHS, and assignment operator
> > suddenly can't?
> >
> > Why the adhoc naming and conceptual shift on the AST level, when
> > PEP572 explicitly talks about *assignment operator*, but
> > corresponding node on the AST level is called NamedExpr? Why look
> > at assignment expression as "name of expression" instead of
> > assignment expression per se?
> >
> > It's of course not a problem to recast:
> >
> > NamedExpr(expr target, expr value)
> >
> > to
> >
> > NamedExpr(expr* target, expr value)
> >
> > in the ASDL (and it works out of the box), the point is that it
> > should have been ExprAssign from the start (folloing the AugAssign
> > and AnnAssign tradition).
> >
> >
> > --
> > Best regards,
> > Paul mailto:[email protected]
> > ___
> > Python-Dev mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/[email protected]/message/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
>
[Python-Dev] Re: What's up with assignment expression and tuples?
This was intentional in PEP 572 so it is not a grammar bug fix.
Put your money where your mouth is, or become another armchair language
designer. Your choice.
On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky wrote:
> Hello,
>
> On Sun, 7 Feb 2021 13:10:55 -0800
> Guido van Rossum wrote:
>
> > Hi Paul,
> >
> > I suggest that you just go straight to the PEP phase.
>
> Thanks. In all fairness, I don't expect immediate resolution to this
> issue. But I'm aware of out for at least a year, and keep returning to
> it (yes, in context of my SSA experiments). So, I proceeded to the next
> stage - bring it up on its own, then created a bug ticket:
> https://bugs.python.org/issue43143
>
> And my idea is to try to argue that it would be just a "grammar
> bugfix", similarly to already existing grammar elaborations for walrus:
>
> https://bugs.python.org/issue42316
> https://bugs.python.org/issue42374
> https://bugs.python.org/issue42381
>
> Granted, allowing "foo((a, b) := (b, a))" is a bit bigger change than
> allowing "foo[a := b]" instead of "foo[(a := b)]". But if people
> find assigning within index expression useful, up to reporting it, and
> then other people ack it and fix it, then why not fix parallel
> assignment case? Implementation-wise they *seem* to be of the
> similar effort/complexity - just a one-term grammar change. (I still
> need to run the testsuite, yeah).
>
>
> >
> > --Guido
> >
> > On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky
> > wrote:
> >
> > > Hello,
> > >
> > > Everyone knows how hard to find a compelling usecase for the
> > > assignment expression operator (":=", colloquially "walrus
> > > operator"). https://www.python.org/dev/peps/pep-0572/ examples
> > > never felt compelling and we all remember the split it caused.
> > >
> > > I finally found a usecase where *not* using assignment expression is
> > > *much* worse than using it. I'm working on SSA (Static Single
> > > Assignment,
> > > https://en.wikipedia.org/wiki/Static_single_assignment_form)
> > > conversion of Python programs, where there's a need to "join"
> > > dataflow of values from different control flow paths using a
> > > special function (Phi function). This "joining" itself creates a
> > > new variable, and of course, the original variable was used in an
> > > expression. We've got assignment in expression, assignment
> > > expression operator to the rescue!
> > >
> > > With it, a simple loop like:
> > >
> > >
> > > a = 0
> > > while a < 5:
> > > a += 1
> > >
> > >
> > > becomes:
> > >
> > >
> > > a0 = 0
> > > while (a1 := phi(a0, a2)) < 5:
> > > a2 = a1 + 1
> > >
> > >
> > > So far, so good. But semantics of Phi function is parallel
> > > assignment. No problem with Python either, "a, b = b, c" is exactly
> > > parallel assignment. So, let's try example with 2 variables:
> > >
> > >
> > > a = 0
> > > b = 10
> > > while a < 5:
> > > a += 1
> > > b += 1
> > >
> > >
> > > becomes:
> > >
> > >
> > > a0 = 0
> > > b0 = 10
> > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > > a2 = a1 + 1
> > > b2 = b1 + 1
> > >
> > >
> > > But oops:
> > >
> > > > SyntaxError: cannot use assignment expressions with tuple
> > >
> > > To reproduce in the REPL:
> > >
> > >
> > > >>> ((a, b) := (1, 2))
> > > File "", line 1
> > > SyntaxError: cannot use assignment expressions with tuple
> > >
> > >
> > > Why this accidental syntactic gap? Why assignment statement can do
> > > parallel assignment with a tuple on LHS, and assignment operator
> > > suddenly can't?
> > >
> > > Why the adhoc naming and conceptual shift on the AST level, when
> > > PEP572 explicitly talks about *assignment operator*, but
> > > corresponding node on the AST level is called NamedExpr? Why look
> > > at assignment expression as "name of expression" instead of
> > > assignment expression per se?
> > >
> > > It's of course not a problem to recast:
> > >
> > > NamedExpr(expr target, expr value)
> > >
> > > to
> > >
> > > NamedExpr(expr* target, expr value)
> > >
> > > in the ASDL (and it works out of the box), the point is that it
> > > should have been ExprAssign from the start (folloing the AugAssign
> > > and AnnAssign tradition).
> > >
> > >
> > > --
> > > Best regards,
> > > Paul mailto:[email protected]
> > > ___
> > > Python-Dev mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> > > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > > Message archived at
> > >
> https://mail.python.org/archives/list/[email protected]/message/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> > *Pronouns: he/him **(why is my pronoun here?)*
> > <
> http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
> >
>
>
>
> -
[Python-Dev] Re: What's up with assignment expression and tuples?
Hello, On Mon, 8 Feb 2021 07:26:27 -0800 Guido van Rossum wrote: > This was intentional in PEP 572 so it is not a grammar bug fix. > > Put your money where your mouth is, or become another armchair > language designer. Your choice. Thanks for encouragement ;-). Adding "const" on the language level is still first on my list, and I'm pretty far from a PEP for it either ;-). > > On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky > wrote: > > > Hello, > > > > On Sun, 7 Feb 2021 13:10:55 -0800 > > Guido van Rossum wrote: > > > > > Hi Paul, > > > > > > I suggest that you just go straight to the PEP phase. > > > > Thanks. In all fairness, I don't expect immediate resolution to this > > issue. But I'm aware of out for at least a year, and keep returning > > to it (yes, in context of my SSA experiments). So, I proceeded to > > the next stage - bring it up on its own, then created a bug ticket: > > https://bugs.python.org/issue43143 [] -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/EOZ6DFOVEJZXJ5Z7S3MYPBQ542FJJIKV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Comments on PEP 558
Hi Mark, On 04.02.21 12:47, Mark Shannon wrote: Hi Sven, On 04/02/2021 9:06 am, Sven R. Kunze wrote: As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy. Out of interest, why would you want to add new keys to the locals of a function frame? I use it for remote execution in human-friendly manner. I plan to opensource the lib for everybody to use, so I was a worried that this change could break it. The function will never be able to use those values. I realize quite now that the use-case usually is on module-level where locals=globals: >>> import sys >>> frame=sys._getframe(0) >>> frame.f_locals['testvar']='testvalue' >>> print(testvar) testvalue >>> So, setting a var was never an issue; also probably because it's seldomly used in this context. Funny enough, that the lib would even start to work properly when functions-locals would be writable. Regards, Sven ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/S3QQKTVFXWBMAETNDNXNLYZDJABGHT63/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Change windows installation program name
I raise https://bugs.python.org/issue43156 that suggests that new users on windows would be less confused if the name of the installation program did not seem to imply it was the python program. In a nutshell the proposal is to change from this: python-3.10.0a5.exe python-3.10.0a5-amd64.exe to this (thanks to Matthew Barnett for the improved names: python-3.10.0a5-win32-setup.exe python-3.10.0a5-win64-setup.exe Barry ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SXB6YSFYBIJAIPXE2VROFCAYAG4TO4EF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Change windows installation program name
You want to make a poll or something? Discourse can do that: https://meta.discourse.org/t/how-to-create-polls/77548 On 08.02.2021 23:07, Barry Scott wrote: I raise https://bugs.python.org/issue43156 that suggests that new users on windows would be less confused if the name of the installation program did not seem to imply it was the python program. In a nutshell the proposal is to change from this: python-3.10.0a5.exe python-3.10.0a5-amd64.exe to this (thanks to Matthew Barnett for the improved names: python-3.10.0a5-win32-setup.exe python-3.10.0a5-win64-setup.exe Barry ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SXB6YSFYBIJAIPXE2VROFCAYAG4TO4EF/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JZUA24QCWCJ5BJ4OLO4QIDHM3KJNACVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language. We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient. At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received little support from core developers. PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax, although the SC understands the desire to improve those aspects of the Pattern Matching proposal. Regarding that, we would also like to mention that changes building on top of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be submitted via the PEP process for review using the regular channels (discussions in python-dev or the https://discuss.python.org/ server), followed by a formal submission to the Steering Council for consideration, taking into account that backwards-incompatible changes can only be made before the feature freeze point of Python 3.10. See PEP 619 (https://www.python.org/dev/peps/pep-0619/) for details on the release schedule for Python 3.10. We know that Pattern Matching has been a challenging feature that has sparked considerable discussions and design conversations, leading to several revisions from feedback stemming from the community, core devs, and the Steering Council. We are very happy to see that the Python developer community remains passionate and respectful, and we are sure that the result has benefited a lot because of it. Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel, Talin, and everyone that participated in the discussion and implementation of this important new feature! -The Python Steering Council ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
On 2/8/21 12:07 PM, Python Steering Council wrote: After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. Yay! Congratulations Guido, Brandt, Tobias, Daniel, and Talin! -- ~Ethan~ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/U4O6VKCDJWHNBSECPNG3IL2R3J5JSNCY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PR Review request - bpo-41928: Add support for Unicode Path Extra Field in ZipFile
On 2/7/2021 1:55 PM, Andrea Giudiceandrea via Python-Dev wrote: Hi Python Dev team, I submitted a PR https://github.com/python/cpython/pull/23736 two months ago. The PR, which fixes an issue https://bugs.python.org/issue41928 in ZipFile, is "awaiting core review". I nosied and requested a review from the active zipfile 'expert' (Serhiy). -- Terry Jan Reedy ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/RWZDYKBRQRTXYUCC6RSA6LF77YJ32YCO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Change windows installation program name
On 2/8/2021 3:12 PM, Ivan Pozdeev via Python-Dev wrote: You want to make a poll or something? Discourse can do that: https://meta.discourse.org/t/how-to-create-polls/77548 On 08.02.2021 23:07, Barry Scott wrote: I raise https://bugs.python.org/issue43156 that suggests that new users on windows would be less confused if the name of the installation program did not seem to imply it was the python program. In a nutshell the proposal is to change from this: python-3.10.0a5.exe python-3.10.0a5-amd64.exe to this (thanks to Matthew Barnett for the improved names: python-3.10.0a5-win32-setup.exe python-3.10.0a5-win64-setup.exe No poll needed, just agreement from the Window people and in particular the person (Steve Dower) who makes the file. Marking the components 'installation' and 'Windows', which I just die, will get their/his attention. (As author, you can also mark components.) -- Terry Jan Reedy ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/Q4T652EFSTX4R4GD7RSZLDQTHQIKPNCL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
On Tue, 9 Feb 2021, 6:21 am Python Steering Council, < [email protected]> wrote: > After much deliberation, the Python Steering Council is happy to announce > that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, > collectively known as the Pattern Matching PEPs. We acknowledge that > Pattern Matching is an extensive change to Python and that reaching > consensus across the entire community is close to impossible. Different > people have reservations or concerns around different aspects of the > semantics and the syntax (as does the Steering Council). In spite of this, > after much deliberation, reviewing all conversations around these PEPs, as > well as competing proposals and existing poll results, and after several > in-person discussions with the PEP authors, we are confident that Pattern > Matching as specified in PEP 634, et al, will be a great addition to the > Python language. Thank you for resolving this discussion - I'm sure it wasn't an easy decision. Obviously I think we're going to find things to regret in the way name binding works in class and mapping patterns, but I also think using "_ as name" as an explanatory tool is likely to cover most of them. I'll also consider submitting a PEP *adding* explicit patterns to the implicit ones, rather than proposing to replace them, so the handling of different kinds of bare expressions can be readily explained as syntactic shorthand for more explicit operations rather than the shorthand being the only available spelling. I won't do that until after helping with the review of the main PEP 634 implementation, though. Cheers, Nick. > > > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OMXOT2NCMJBJBLFLMHRZDSIHN6Z7CEDT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] bpo-42819 PR review request
Hello, I submitted https://bugs.python.org/issue42819 a little over a month ago with an accompanying PR: https://github.com/python/cpython/pull/24108. Would it be possible to get feedback on it? This addresses a bug that occurs when Python is compiled with the most recent release of GNU Readline and affects both Linux and macOS. Thanks, Dustin ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5GHQPXP37QMI4SQPJFI7SUBE4HGOOON4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?
Hi everywhere.
I decided to figure out why it is impossible to change methods of built-in
types and found
```
if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
PyErr_Format(
PyExc_TypeError,
"can't set attributes of built-in/extension type '%s'",
type->tp_name);
return -1;
}
```
in function type_setattro.
If comment this line and try to patch method __eq__ on the list for example the
code will work as expected
Test:
```
with patch("builtins.list.__eq__", return_value=False):
assert [] == []
```
Result: `AssertionError` as expected. Is there a real need to disallow patching
of built-in types or is it just legacy?
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/FYS52CPAN7EMSQF4WF3WM5VNO52TBOIT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
Hello, On Tue, 9 Feb 2021 08:56:02 +1000 Nick Coghlan wrote: > > After much deliberation, the Python Steering Council is happy to > > announce that we have chosen to accept PEP 634, and its companion > > PEPs 635 and 636, collectively known as the Pattern Matching PEPs. > > We acknowledge that Pattern Matching is an extensive change to > > Python and that reaching consensus across the entire community is > > close to impossible. Different people have reservations or > > concerns around different aspects of the semantics and the syntax > > (as does the Steering Council). In spite of this, after much > > deliberation, reviewing all conversations around these PEPs, as > > well as competing proposals and existing poll results, and after > > several in-person discussions with the PEP authors, we are > > confident that Pattern Matching as specified in PEP 634, et al, > > will be a great addition to the Python language. > > Thank you for resolving this discussion - I'm sure it wasn't an easy > decision. > > Obviously I think we're going to find things to regret in the way name > binding works in class and mapping patterns, but I also think using > "_ as name" as an explanatory tool is likely to cover most of them. > > I'll also consider submitting a PEP *adding* explicit patterns to the > implicit ones, rather than proposing to replace them, so the handling > of different kinds of bare expressions can be readily explained as > syntactic shorthand for more explicit operations rather than the > shorthand being the only available spelling. Also, +100 for resubmitting on its own just the part of PEP642 which adds "== EXPR" and "is EXPR" syntax, to match by expression value (i.e. where PEP642 initially started from). > I won't do that until after helping with the review of the main PEP > 634 implementation, though. > > Cheers, > Nick. -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SE2YVL2XLCZGOZTHU5YNFLTES5KFFRB5/ Code of Conduct: http://python.org/psf/codeofconduct/
