I've pretty much always taught using the "comprehension" term. It makes sense to introduce comprehensions on concrete collections first. Then I typically say something like "This special kind of comprehension is called a 'generator expression'". Usually that's accompanied by a motivation like creating a listcomp of a hundred million items, then showing that creating the generator expression is instantaneous.

However, after the initial introduction, I consistently call it a generator expression. Albeit, for the students I teach—data scientists and quants, mostly—there's not a lot of time spent on that being the introduction (by then I'm talking about NumPy and Pandas, and scikit-learn, and Seaborn, abd Statsmodels, and so on. If things are "lazy" it's because they are Dask deferred or Dask DataFrame.

On Sun, Jul 15, 2018, 1:02 PM Chris Barker via Python-Dev <python-dev@python.org> wrote:
Thanks Nick,

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 <ncoghlan@gmail.com> wrote:
On 13 July 2018 at 15:30, Chris Barker via Python-Dev
<python-dev@python.org> wrote:
> On Mon, Jul 9, 2018 at 3:18 PM, Guido van Rossum <guido@python.org> wrote:
>> 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":

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:

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:

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

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   |   ncoghlan@gmail.com   |   Brisbane, Australia


Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Python-Dev mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx