On Sun, Jul 12, 2020 at 7:36 PM Greg Ewing
wrote:
> On 13/07/20 7:12 am, Larry Hastings wrote:
> > I dimly recall a precedent where the
> > presence of locals() in a function body affected code generation,
>
> The presence of exec used to do that, which is why it was a
> statement rather than a
On 13/07/20 7:12 am, Larry Hastings wrote:
I dimly recall a precedent where the
presence of locals() in a function body affected code generation,
The presence of exec used to do that, which is why it was a
statement rather than a function. But I don't think locals()
ever did -- how would the
On 7/11/2020 6:31 PM, Guido van Rossum wrote:
Hm... Just the fact that people have been arguing both sides so
convincingly makes me worry that something bigger is amiss. I think
we're either better off without `else` (since the indentation of `case
_` cannot be disputed :-), or we have to
On 2020-07-12 23:20, Guido van Rossum wrote:
[snip]
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*
On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings wrote:
> Having thought about it some, I propose it'd be acceptable to do dead
> store optimization if-and-only-if optimizations are explicitly enabled,
> e.g. with "-O". Allowing explicitly-enabled optimizations to observably
> affect runtime
Having followed this discussion for a while, I'm trying to put my finger on
why I feal uneasy about it.
The major features I see in this proposal are:
* New syntax for trying multiple assignments until one matches.
* Extending destructuring assignment to match constants in the LHS.
On 07/11/2020 03:31 PM, Guido van Rossum wrote:
On Sat, Jul 11, 2020 at 2:45 PM Ethan Furman wrote:
On 07/11/2020 10:29 AM, Jim J. Jewett wrote:
To me, "else:" has a slightly different meaning than "case _:"
case _: essentially a default, ensuring that the match logic is
On Jul 11, 2020, at 13:28, MRAB wrote:
> Another possibility is:
>
>match:
>...
>case ...:
>case ...:
It’s ugly, but you could introduce and require a (soft) keyword on the line
after match, e.g.
match:
# Can’t really use `with` here although I think it reads better.
On 7/11/2020 7:54 PM, Greg Ewing wrote:
I can see that being a reasonable choice if you're using 8-space
indents, but I don't see that done much in Python.
Also, directly translating this into Python leads to something that
looks like a mistake:
match x:
case 1:
...
case
On 7/12/20 9:04 AM, Daniel Moisset wrote:
The existing implementation has optimizations here. If that's
important, we could achieve the same result with a little dataflow
analysis to optimize away the dead store. We could even
special-case optimizing away dead stores /only/ to
Rhodri James wrote:
> Eric Nieuwland wrote:
>
>> Just after I hit ‘send’ it dawned on me it might be preferable to make that
>>
>> match poly:
>> p0 = Point(x0, y0)
>> p1 = Point(x1, y1)
>> p2 = Point(x2, y2)
>> case Polygon(p0, p1, p2):
>> …
>>
>> so the part preceded by
On Sun, Jul 12, 2020 at 1:16 PM Jim J. Jewett wrote:
> Federico Salerno wrote:
> > On 11/07/2020 19:29, Jim J. Jewett wrote:
> > > To me, "else:" has a slightly different meaning than "case _:" ...
>
> > Could you construct two examples to prove behaviour would be different
> > between the two?
Greg Ewing wrote:
> Eric Nieuwland wrote:
>
>> ...
>> match poly:
>> p0 = Point(x0, y0)
>> p1 = Point(x1, y1)
>> p2 = Point(x2, y2)
>> case Polygon(p0, p1, p2):
>> …
>>
>
> Interesting idea, but what happens if you don't
> need any setup?
> Do you have to write
>
Federico Salerno wrote:
> On 11/07/2020 19:29, Jim J. Jewett wrote:
> > To me, "else:" has a slightly different meaning than "case _:" ...
> Could you construct two examples to prove behaviour would be different
> between the two?
The behavior would be identical; the difference is in why I put
Hey Larry, just to clarify on a single point you make:
On Sun, 12 Jul 2020 at 10:48, Larry Hastings wrote:
> [ snip ]
> To address 2), bind '_' when it's used as a name in a pattern.
>
> This adds an extra reference and an extra store. That by itself seems
> harmless.
>
This is not always
On 7/12/20 2:38 AM, Federico Salerno wrote:
Was anything beside _ and ... proposed?
Yes, the PEP mentions using '?'. It isn't the authors' first choice but
it seems they're not dead-set against it either. Personally I prefer it
to special-casing '_'. It has no meaning in Python syntax
On Sun, 12 Jul 2020 at 10:47, Larry Hastings wrote:
> In that case, I'd like to make a specific pitch for "don't make '_' special".
> (I'm going to spell it '_' as it seems to be easier to read this way; ignore
> the quotes.)
Overall, this sounds mostly reasonable. I'm cutting nearly
On 11/07/2020 12:20, Paul Sokolovsky wrote:
Actually, the whole argument in PEP 622 regarding "else:", that its
placement is ambiguous sounds like a rather artificial write-off.
Individual "case"'s are aligned together, but suddenly, it's unclear
how to align the default case, introduced by
On 11/07/2020 20:13, Eric Nieuwland wrote:
Just after I hit ‘send’ it dawned on me it might be preferable to make that
match poly:
p0 = Point(x0, y0)
p1 = Point(x1, y1)
p2 = Point(x2, y2)
case Polygon(p0, p1, p2):
On 12/07/2020 11:38, Larry Hastings wrote:
In that case, I'd like to make a specific pitch for "don't make '_'
special". (I'm going to spell it '_' as it seems to be easier to read
this way; ignore the quotes.)
IIUC '_' is special in two ways:
1) we permit it to be used more than once in a
On 11/07/2020 19:29, Jim J. Jewett wrote:
To me, "else:" has a slightly different meaning than "case _:" case _:
essentially a default, ensuring that the match logic is complete.
else: OK, the subject of this match failed, here is our fallback
logic. Whether this distinction is important
On 7/8/20 8:02 AM, Guido van Rossum wrote:
Regarding the syntax for wildcards and OR patterns, the PEP explains
why `_` and `|` are the best choices here: no other language surveyed
uses anything but `_` for wildcards, and the vast majority uses `|`
for OR patterns. A similar argument applies
I don't think anyone has asked for more indentation in that sense; it has only
even come up in a suggestion of less. (2-space indents for case instead of 4)
People do disagree about whether or not case statements (and possibly an else
statement) should be indented more than 0 spaces compared
23 matches
Mail list logo
