On 6 May 2018 at 02:06, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 4 May 2018 at 22:06, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
