[Python-ideas] A "local" pseudo-function

[Ed Kellett]

On 2018-04-28 21:40, Tim Peters wrote:
> [Ed Kellett <e+python-ideas at kellett.im>]
>> How about if you just can't have an expression in a local()?
> 
> See the quadratic equation example in the original post.  When 
> working with expressions, the entire point of the construct is to 
> define (sub)local names for use in a result expression.
> 
> [snip]
> 
> Requiring "in" requires annoying syntactic repetition in the common
> 
> if local(match=re.match(regexp, line)) in match:
> 
> kinds of cases.

I don't mean "in" should be required, but rather that the last thing is
always an assignment, and the local() yields the assigned value.

So that'd remain:

    if local(match=re.match(regexp, line)):

whereas your quadratic equation might do the "in" thing:

    r1, r2 = local(D = b**2 - 4*a*c,
                   sqrtD = math.sqrt(D),
                   twoa = 2*a) in (
                       (-b + sqrtD)/twoa, (-b - sqrtD)/twoa)

... which doesn't look particularly wonderful (I think it's nicer with
my option 3), but then I've never thought the quadratic equation was a
good motivating case for any version of an assignment expression.

In most cases I can imagine, a plain local() would be sufficient, e.g.:

    if local(match=re.match(regexp, line)) and match[1] == 'frog':

> Making "in" optional instead was discussed near the end of the 
> original post.  I agree that your spelling just above is more obvious
> than `local(x=1, y=2, x+y)` which is why the original post discussed
> making an "in clause" optional.  But, overwhelmingly, it appears that
> people are more interested in establishing sublocal scopes in `if`
> and `while` constructs than in standalone expressions, so I picked a
> spelling that's _most_ convenient for the latter's common "just name
> a result and test its truthiness" uses.
> 
> [snip]
> 
> Indeed, 3 is the only one I'd consider, but I don't see that it's a 
> real improvement.  It seems to require extra typing every time just 
> to avoid learning "and it returns the value of the last expression" 
> once.

I agree with pretty much all of this--I was trying to attack the "but
you could make the terrible C mistake" problem from another angle. I
don't think I mind the last "argument" being *allowed* to be an
expression, but if the consensus is that it makes '='/'==' confusion too
easy, I think it'd be more straightforward to say they're all
assignments (with optional, explicit syntax to yield an expression) than
to say "they're all assignments except the last thing" (argh) "except in
the special case of one argument" (double argh).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180428/c4c5a81d/attachment.sig>