On Sat, Oct 31, 2020 at 21:48 Dan Stromberg wrote:
>
> On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum wrote:
>
>>
>> I think this over-stresses the notion that users might want to override
>> the comparison operator to be used. We only have two operators that make
>> sense in this context, 'is
On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum wrote:
>
> I think this over-stresses the notion that users might want to override
> the comparison operator to be used. We only have two operators that make
> sense in this context, 'is' and '==', and really, for almost everything you
> want to do
On Sat, Oct 31, 2020 at 6:30 PM Nick Coghlan wrote:
> On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano,
> wrote:
>
>>
>>
>>
>> (3) Overriding the default comparison with an explicit sigil is
>> allowed:
>>
>>
>> case ==True:
>> print("True, or 1, or 1.0, or 1+0j, etc")
>>
>> case =
On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano, wrote:
>
>
>
> (3) Overriding the default comparison with an explicit sigil is
> allowed:
>
>
> case ==True:
> print("True, or 1, or 1.0, or 1+0j, etc")
>
> case ==None:
> print("None, or something weird that equals None")
>
Hello,
On Sat, 31 Oct 2020 18:53:57 +1000
Nick Coghlan wrote:
> On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky
> wrote:
> > I blame it on my Saturday's hazy mind, but also for the interest of
> > other readers, could you elaborate on "`==` interacts poorly with
> > other aspects of the pattern s
Hello,
On Sat, 31 Oct 2020 12:16:09 +
Paul Moore wrote:
> On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano
> wrote:
> >
> > Thank you for the well-written PEP, although I don't agree with it.
> > My response below is quite long. Here is my opinionated TL;DR:
>
> For what it's worth, I find
On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano wrote:
>
> Thank you for the well-written PEP, although I don't agree with it. My
> response below is quite long. Here is my opinionated TL;DR:
For what it's worth, I find your rebuttal of PEP 642 convincing, and
in line with my thoughts on the matter
On Sat, Oct 31, 2020 at 10:22:09PM +1100, Steven D'Aprano wrote:
> (1) Just get over the use of `_` for the wildcard pattern.
> another identifier. Now that the parser will support soft keywords, we
> should expect more cases that something that is an identifier is one
> context will be a keywo
Thank you for the well-written PEP, although I don't agree with it. My
response below is quite long. Here is my opinionated TL;DR:
(1) Just get over the use of `_` for the wildcard pattern.
another identifier. Now that the parser will support soft keywords, we
should expect more cases that som
Hi Nick and Everyone,
We had actually considered a similar idea (i.e. load sigils) during
the design phase of pattern matching. In the interest of having a
rule that is as simple as possible, we had proposed to use a leading
dot as a universal marker. Tin's example would thus have been wr
On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky wrote:
> I blame it on my Saturday's hazy mind, but also for the interest of
> other readers, could you elaborate on "`==` interacts poorly with other
> aspects of the pattern syntax"?
Class patterns use the keyword argument syntax to match by attribu
Hello,
On Sat, 31 Oct 2020 18:01:16 +1000
Nick Coghlan wrote:
> On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky
> wrote:
> > Alternatively, can add "inline guard sigils" for the most common
> > guard conditions, which would be equality, period:
> >
> > match r:
> > case (src, None):
> > c
On 10/30/2020 5:08 PM, Garrett D'Amore via Python-Dev wrote:
I’m not on this list. But I have offered to help - if there are tasks that
need to be done to help this I can help put the weight of a commercial entity
behind it whether that involves assigning our developers to work on this,
helpi
On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky wrote:
> Alternatively, can add "inline guard sigils" for the most common guard
> conditions, which would be equality, period:
>
> match r:
> case (src, None):
> case (==c, msg):
> case (==s, msg):
`==` interacts poorly with other aspects
Hello,
On Sat, 31 Oct 2020 02:37:14 +0100
Tin Tvrtković wrote:
[]
> async def ws_proxy(client: WebSocket):
> await client.accept()
> async with ClientSession() as session:
> async with session.ws_connect("wss://echo.websocket.org") as
> s: c = starlette_websocket_iterator(clien
On Sat, 31 Oct 2020 at 00:44, Mark Shannon wrote:
> Should match be an expression, or a statement?
> --
>
> Do we want a fancy switch statement, or a powerful expression?
> Expressions have the advantage of not leaking (like comprehensions in
> Python 3)
Hi folks,
This is a mailing list repost of the Discourse thread at
https://discuss.python.org/t/pep-642-constraint-pattern-syntax-for-structural-pattern-matching/5614
The rendered version of the PEP can be found here:
https://www.python.org/dev/peps/pep-0642/
The full text is also quoted in the
On Fri, 30 Oct 2020 at 23:34, Victor Stinner wrote:
>
> Le ven. 30 oct. 2020 à 11:02, Nick Coghlan a écrit :
> > > Ok, I've created https://bugs.python.org/issue42197 to track it.
> >
> > Please also have a look at PEP 558 and its draft reference
> > implementation at https://github.com/python/cp
18 matches
Mail list logo
