On 2018-04-29 18:01, Tim Peters wrote:
[Tim]
>> ...
>> This is the kind of code about which there have been background
>> complaints "forever":
>>
>> m1 = regexp1.match(line)
>> m2 = regexp2.match(iine)
>> if m1 and m2:
>> do all sorts of stuff with m1 and/or m2,
>> including perhaps modifying local variables
>> and/or global variables
>> and/or nonlocal variables
>>
>> The complaints are of two distinct kinds:
>>
>> 1. "I want to compute m1 and m2 _in_ the `if` test".
>>
>> 2. "I don't want these temp names (m1 and m2) accidentally
>> conflicting with local names already in scope - if these names
>> already exist, I want the temp names to shadow their
>> current bindings until the `if` structure is done".
>>
>> So,
>>
>> if local(m1=regexp1.match(line),
>> m2 = regexp2.match(iine),
>> m1 and m2):
>>
>> intends to address both complaints via means embarrassingly obvious to
>> the most casual observer ;-)
[MRAB <pyt...@mrabarnett.plus.com>]
> How about these:
>
> local m1, m2:
> m1 = regexp1.match(line)
> m2 = regexp2.match(line):
> if m1 and m2:
> ...
>
>
> local m1, m2:
>
> if (m1 := regexp1.match(line)) and (m2 := regexp2.match(line)):
>
> ...
>
> local m1=regexp1.match(line), m2=regexp2.match(line):
> if m1 and m2:
They address complaint #2 in what seems to me a thoroughly Pythonic
(direct, transparent, no more magical than necessary, easy to read)
way. They don't address complaint #1 at all, but as you've shown (in
the 2nd spelling) that isn't _inherently_ tied to complaint #2
(complaint #1 is what PEP 572 addresses).
So _if_ PEP 572 is accepted, adding this form of a compound `local`
statement too would address both of the listed complaints, at the
"cost" of a bit more typing and adding a level of indentation.
Neither of which bother me ;-)
`local()` itself was also intended to address the
even-more-in-the-background recurring desires for an expression (as
opposed to statement) oriented way to use throwaway bindings; e.g.,
instead of
temp = x + y - z + 1
r = temp**2 - 1/temp
this instead:
r = local(t=x + y - z + 1, t**2 - 1/t)
It's not an accident that the shorter `t` is used in the latter than
the former's `temp`: when people are wary of clobbering names by
accident, they tend to use longer names that say "I'm just a temp -
please don't _expect_ my binding to persist beyond the immediate uses
on the next few lines":.
Anyway, that kind of thing is common n functional languages, where
"let" pile-of-bindings "in" expression
kinds of constructs are widely used _as_ (sub)expressions themselves.
local t = x + y - z + 1:
r = t**2 - 1/t
would be the same semantically, but they'd still complain about the
"extra" typing and the visual "heaviness" of introducing a block for
what they _think_ of as being "just another kind of expression".
The `local()` I brought up was, I think, far too biased _toward_ that
use. It didn't "play nice" with block-oriented uses short of
excruciatingly deep magic. Your `local` statement is biased in the
other direction, but that's a Good Thing :-)
As well as:
local t = x + y - z + 1: r = t**2 - 1/t
I wonder if it could be rewritten as:
r = local t = x + y - z + 1: t**2 - 1/t
Would parentheses be needed?
r = (local t = x + y - z + 1: t**2 - 1/t)
It kind of resembles the use of default parameters with lambda!
The names would be local to the suite if used as a statement or the
following expression if used in an expression, either way, the bit after
the colon.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
