I think we are storing up trouble unless we
1) Allow arbitrary expressions after `case`, interpreted *as now*
2) Use *different* syntaxes, not legal in expressions, for
alternative matching values (i.e. not `|` or `or`) (NB
simply stacking with multiple `case` lines is one
Hi Rob,
You are right: the grammar should probably read `suite` rather
than `block` (i.e. the `pass` is necessary). Thanks for catching
this!
As for the second question, I assume there might be a slight
oversight on your part. The last line in the example replaces the
string `"_"` rather
On 24/06/2020 20:38, Guido van Rossum wrote:
Everyone,
If you've commented and you're worried you haven't been heard, please
add your issue *concisely* to this new thread. Note that the following
issues are already open and will be responded to separately; please
don't bother commenting on
Without arguing for or against allowing a capture variable, IMO rather
than syntax like
match into :
it would be far better (and not require a new keyword) to write this as
with as match :
Rob Cliffe
On 24/06/2020 20:38, Guido van Rossum wrote:
Everyone,
If you've commented and
On 08/07/2020 16:15, MRAB wrote:
On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:
Why not use '=' to distinguish binding from equality testing:
case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.
This would allow a future (or present!)
On 9/07/20 3:26 am, Brandt Bucher wrote:
match :
case | : ...
case | if : ...
case | : ...
```
It's safe to use the same decision tree for through , but it must be rebuilt for
and , since could have done literally *anything*.
I think you're being overly cautious here.
Inada Naoki wrote:
> Since this is very new system, can we have some restriction to allow
> aggressive optimization than regular Python code?
The authors were just discussing a related question yesterday (more
specifically, can the compiler fold `C() | C()` -> `C( | )`).
The answer we arrived
On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:
Why not use '=' to distinguish binding from equality testing:
case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.
This would allow a future (or present!) extension to other relative
operators:
On 7/7/20 10:08 PM, Rob Cliffe via Python-Dev wrote:
> Why not use '=' to distinguish binding from equality testing:
> case Point(x, =y): # matches a Point() with 2nd parameter equal to
> y; if it does, binds to x.
>
> This would allow a future (or present!) extension to other relative
>
On Wed, Jul 8, 2020 at 8:56 PM Inada Naoki wrote:
>
> On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote:
> >
> >
> > These two I would be less averse to, but the trouble is that they make
> > the semantics a bit harder to explain. "Dotted names are looked up if
> > not already looked up,
On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote:
>
>
> These two I would be less averse to, but the trouble is that they make
> the semantics a bit harder to explain. "Dotted names are looked up if
> not already looked up, otherwise they use the same object from the
> previous lookup". If you
On 08/07/2020 11:05, Federico Salerno wrote:
What I don't like is the use of _ as catch-all, which is different and
not interdependent with its use as throwaway.
Any name used as a pattern is a catch-all. The only difference between
"case dummy:" and "case _:" is that "_" doesn't bind to the
On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote:
I used to be in this "camp", however, a (I think valid) point was
raised that "else:" is not a (full) alternative. Due to the
restriction on repeated names (e.g. Point(x, x) is illegal), if you
want to "throw away" intermediate matches, you will
On Wed, Jul 8, 2020 at 6:17 PM Inada Naoki wrote:
>
> Since this is very new system, can we have some restriction
> to allow aggressive optimization than regular Python code?
>
> # Class Pattern
>
> Example:
>
> match val:
> case Point(0, y): ...
> case Point(x, 0): ...
>
Since this is very new system, can we have some restriction
to allow aggressive optimization than regular Python code?
# Class Pattern
Example:
match val:
case Point(0, y): ...
case Point(x, 0): ...
case Point(x, y): ...
* Can VM lookup "Point" only once per
On Sun, Jun 28, 2020 at 8:44 AM Jim J. Jewett wrote:
> I actually like that it looks like instantiation; it seems to be saying
> "Do we have the sort of object we would get from this instantiation?"
>
> Unfortunately, this does aggravate the confusion over whether a variable
> is being used as a
Why not use '=' to distinguish binding from equality testing:
case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.
This would allow a future (or present!) extension to other relative
operators:
case Point(x, >y):
(although the syntax doesn't
I wrote:
>
> Guido van Rossum wrote:
>
>> Eric Nieuwland wrote:
>>
>>> I have some doubt about the keyword: ‘match' seems to be at odds with
>>> 'for', 'while', 'with', 'if' as it is more of an action.
>>> It's more like 'try' but that statement has a completely different
>>> structure.
>>
>>
I actually like that it looks like instantiation; it seems to be saying "Do we
have the sort of object we would get from this instantiation?"
Unfortunately, this does aggravate the confusion over whether a variable is
being used as a filter, vs binding to something from the matched object.
What about `case for Point(x, 0):`? It reads very naturally, the presence of
"for" hints against Point() being a call to the class, and "for" is an existing
keyword that would make no other sense in that position.
Examples with other formats such as `case for [x, 0]:` seem to work just as
well.
On Thu., 25 Jun. 2020, 5:41 am Guido van Rossum, wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't
This one is new but I think unrelated and unmentioned:
Why is the mapping match semantics non-strict about keys? Besides the
"asymmetry" with sequence matches, I think a strict match should be useful
sometimes (quickly deconstructing JSON data comes to my mind, where I want
to know that I didn't
On Fri, Jun 26, 2020 at 3:47 AM Paul Moore wrote:
> For me, this prompts the question (which I appreciate is more about
> implementation than design) - would there be any (significant)
> performance difference between [...]
> In C, the switch statement was explicitly intended to be faster by
>
On Fri, 26 Jun 2020 at 11:29, Daniel Moisset wrote:
>
> I think roughly half of the uses will actually be for "the switch statement
> we never had", where all branches would be constants. I've been writing a lot
> of code like that these last couple of weeks, so I may be biased (although
> the
[apologies for the duplicate to Guido, used reply instead of reply to all]
To summarize my previous unanswered post, I posted a +1 to the "defaulting
to binding vs interpreting NAME as a constant" is a dangerous default. And
I submitted a couple of alternate syntactic ways to denote "capture is
On 26/06/20 6:21 am, Pablo Galindo Salgado wrote:
Which means that users can do a positional match against the proxy with
a name pattern:
match input:
case datetime.date(dt):
print(f"The date {dt.isoformat()}"
I think that would be an incorrect way for matching on datetime
to
On 26/06/20 12:31 pm, Brandt Bucher wrote:
I'd imagine that we either find some straightforward way of > opting-in to the
current default behavior
Maybe special-case 'self' in __match_args__ to mean the
object being matched?
--
Greg
___
Python-Dev
Ethan Furman wrote:
> Ouch. That seems like a pretty serious drawback. Will this issue be
> resolved?
It's currently being revisited.
Realistically, I'd imagine that we either find some straightforward way of
opting-in to the current default behavior (allowing one arg to be positionally
On 06/25/2020 04:07 PM, Brandt Bucher wrote:
Pablo Galindo Salgado wrote:
...users can do a positional match against the proxy with a name pattern:
match input:
case datetime.date(dt):
print(f"The date {dt.isoformat()}"
...if 'datetime.date' were updated to implement a
Pablo Galindo Salgado wrote:
> ...users can do a positional match against the proxy with a name pattern:
>
> match input:
> case datetime.date(dt):
> print(f"The date {dt.isoformat()}"
>
> ...if 'datetime.date' were updated to implement a non-default __match_args__,
> allowing
On Wed, Jun 24, 2020 at 12:46 PM Guido van Rossum wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't
I was talking with a colleague today about the PEP and he raised a couple
of question regarding the match protocol and the proxy result.
One question is that taking into account that 'case object(x)' is valid for
every object, but it does (could do) something different for objects
that have a
> '?foo' or 'foo?' to mark a variable binding
I like that idea a lot, with a strong inclination for the '?foo' variant.
Seeing the '?' first makes it clear right away that it's a special context.
And it keeps it more distinct from the None-aware operators (from PEP 505,
in case that gets
On 25/06/2020 10:15, Chris Angelico wrote:
On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote:
On Wed, 24 Jun 2020 12:38:52 -0700
Guido van Rossum wrote:
Everyone,
If you've commented and you're worried you haven't been heard, please add
your issue *concisely* to this new thread. Note
Without arguing for or against allowing a capture variable, IMO rather
than syntax like
match into :
it would be far better (and not require a new keyword) to write this as
with as match :
Rob Cliffe
PS: Or
= match
On 24/06/2020 20:38, Guido van Rossum wrote:
Everyone,
If
On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote:
>
> On Wed, 24 Jun 2020 12:38:52 -0700
> Guido van Rossum wrote:
> > Everyone,
> >
> > If you've commented and you're worried you haven't been heard, please add
> > your issue *concisely* to this new thread. Note that the following issues
> >
On Wed, 24 Jun 2020 12:38:52 -0700
Guido van Rossum wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't
On Wed, 24 Jun 2020 at 16:40, Guido van Rossum wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
I gave a longer example, but the short version is that I cannot tell from
the Class Pattern or Runtime section how class patterns interact with
properties (i.e. when access changes state).
On Wed, Jun 24, 2020, 3:45 PM Guido van Rossum wrote:
> Everyone,
>
> If you've commented and you're
39 matches
Mail list logo
