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

Ed Kellett e+python-ideas at kellett.im
Sat Apr 28 16:12:25 EDT 2018


On 2018-04-28 18:16, Tim Peters wrote:
> [Steven D'Aprano <steve at pearwood.info>]
>> But the biggest problem is that this re-introduces exactly the same
>> awful C mistake that := was chosen to avoid. Which of the following two
>> contains the typo?
>>
>>     local(spam=expression, eggs=expression, cheese = spam+eggs)
>>
>>     local(spam=expression, eggs=expression, cheese == spam+eggs)
> 
> [snip]
> 
> Still, if people are scared of that, a variation of Yury's alternative
> avoids it:  the last "argument" must be an expression (not a binding).
> In that case your first line above is a compile-time error.
> 
> I didn't like that because I really dislike the textual redundancy in the common
> 
>     if local(matchobject=re.match(regexp, line), matchobject):
> 
> compared to
> 
>     if local(matchobject=re.match(regexp, line)):
> 
> But I could compromise ;-)
> 
> - There must be at least one argument.
> - The first argument must be a binding.
> - All but the last argument must also be bindings.
> - If there's more than one argument, the last argument must be an expression.

How about if you just can't have an expression in a local()? There are a
few obvious alternative possibilities:

1. No special case at all:

    local(x=1, y=2, _=x+y)

2. Co-opt a keyword after local():

    local(x=1, y=2) in x+y

3. Co-opt a keyword inside local():

    local(x=1, y=2, return x+y)

I hate the first and wish the _ pattern would die in all its forms, but
it's worth mentioning. I don't think there's much to choose between the
other two, but 2 uses syntax that might have been valid and meant
something else, so 3 is probably less confusing.

-------------- 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/8f3b8f45/attachment.sig>


More information about the Python-ideas mailing list