[Python-ideas] Inline assignments using "given" clauses

[Nick Coghlan]

On 6 May 2018 at 02:06, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 4 May 2018 at 22:06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> (Note: Guido's already told me off-list that he doesn't like the way this
>> spelling reads, but I wanted to share it anyway since it addresses one of
>> the recurring requests in the PEP 572 discussions for a more targeted
>> proposal that focused specifically on the use cases that folks had agreed
>> were reasonable potential use cases for inline assignment expressions.
>>
>> I'll also note that another potential concern with this specific proposal
>> is that even though "given" wasn't used as a term in any easily discovered
>> Python APIs back when I first wrote PEP 3150, it's now part of the
>> Hypothesis testing API, so adopting it as a keyword now would be markedly
>> more disruptive than it might have been historically)
>>
>
> Since I genuinely don't think this idea is important enough to disrupt
> hypothesis's public API, I've been pondering potential synonyms that are
> less likely to be common in real world code, while still being
> comprehensible and useful mnemonics for the proposed functionality.
>

I've also been pondering Tim's suggestion of instead enhancing the code
generation pipeline's native support for pseudo-keywords in a way that can
be explicitly represented in the Grammar and AST, rather than having to be
hacked in specifically every time we want to introduce a new keyword
without a mandatory __future__ statement (and without creating major
compatibility headaches for code that uses those new keywords as attribute
or variable names).

While I haven't actually tried this out yet, the way I'm thinking that
might look is to add the following nodes to the grammar:

    name_plus: NAME | pseudo_keyword
    pseudo_keyword: 'given'

and the replace all direct uses of 'NAME' in the grammar with 'name_plus'.

That way, to allow a new keyword to be used as a name in addition to its
syntactic use case, we'd add it to the pseudo_keyword list in addition to
adding it to .

To avoid ambiguities in the grammar, this could only be done for keywords
that *can't* be used to start a new expression or statement (so it wouldn't
have been sufficient for the async/await case, since 'async' can start
statements, and 'await' can start both statements and expressions).

So if Guido's view on the out-of-order execution approach to inline name
binding softens, I think this would be a better approach to pursue than
making a more awkward keyword choice.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180506/00b358fa/attachment-0001.html>