I'll adopt this approach when I update my teaching materials.
If I think of it, I"ll post here when I do that
On Sun, Jul 15, 2018 at 12:21 AM, Nick Coghlan email@example.com wrote:
On 13 July 2018 at 15:30, Chris Barker via Python-Dev firstname.lastname@example.org wrote:
On Mon, Jul 9, 2018 at 3:18 PM, Guido van Rossum email@example.com
Definitely docs first. And we should keep references to generator expressions too, if only to explain that they've been renamed.
Perhaps someone should try it out in a 3rd party tutorial to see how it goes?
I'm not sure what "trying it out in a tutorial" would look like.
I try to be pretty clear about terminology when I teach newbies -- so I don't want to tell anyone this new thing is called a "generator comprehension" if they aren't going to see that term anywhere else.
Nina Zakharenko made the "they're officially called generator expressions, but I find it more helpful to think of them as generator comprehensions" observation in her PyCon 2018 presentation on "Elegant Solutions for Everyday Python Problems": https://www.slideshare.net/nnja/elegant-solutions-for- everyday-python-problems-pycon-2018/27
The article from Ned Batchelder mentioned in that slide is this one, which goes through the history of Raymond originally proposing the notion as generator comprehensions, them getting changed to generator expressions during the PEP 289 discussions, and then asking if it might be worth going back to the originally suggested name: https://nedbatchelder.com/blog/201605/generator_comprehensions.html
And then in PEP 572, it was found that being able to group all 4 constructs (list/set/dict comps + generator expressions) under a single term was a genuinely useful shorthand: https://www.python.org/dev/peps/pep-0572/#scope-of-the-target
So trying out the terminology in a tutorial context would be to do something similar to what Nina did in her talk: introduce the notion of list/set/dict/generator comprehensions, and then make a side note that the latter are officially referred to as "generator expressions".
This wouldn't be the first time that terminology has differed between Python-as-commonly-taught and Python-as-formally-defined, as I've yet to hear anyone refer to container displays outside a language design discussion - everyone else calls them container literals (or, more typically, a literal for the specific builtin container type being discussed).
In this case, though, we'd be considering eventually changing the language reference as well, and perhaps even some day the AST node name (from GeneratorExp to GeneratorComp).
We wouldn't need to change anything in the grammar definition (since that already shares the comp_for and comp_if syntax definitions between container comprehensions and generator expressions), or the AST node structure (since GeneratorExp already uses a "comprehensions" attribute, the same as the ListComp/SetComp/DictComp nodes).
-- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia