
Python Generator comprehensions - ingve
http://nedbatchelder.com//blog/201605/generator_comprehensions.html
======
danso
I'm relatively new to Python but one of the things I love most about the
community is the easily accessible PEPs...I know Ruby has mailing lists and
discussion groups where changes to the language are hashed out...but I've
never come across anything that resembles PEP, a well-organized list of
articles that aren't just proposals, but well-edited documents that are a
pleasure to read while going in-depth into the reasoning behind the proposal,
the ensuing debate, and how/when/and why action was taken. I've never better
understood a language better than I do Python.

As an example, one of my recent favorites is PEP 495 Local Time Disambiguation
[0] -- a feature which has been approved for 3.6. I can't summarize it
capably, but it covers a topic about time that I hadn't even thought about, in
a very readable yet thorough fashion. I was reminded of it when reading the
OP, because both PEPS involve a seemingly inexplicable naming issue that ends
up having a perfectly rational explanation -- when you think through the
details.

In PEP 495, which adds an attribute named `fold` to datetime objects, there's
debate about whether `fold` is the right term (or rather, why not have the
attribute's name be more closely tied to "daylight savings time")...and the
explanation, which covers past examples of confusion with DST, while
anticipating compatibility issues with pre 3.6 datetime implementation, is
perfectly convincing, as common sense as something can be regarding an
esoteric topic.

[0]
[https://www.python.org/dev/peps/pep-0495/](https://www.python.org/dev/peps/pep-0495/)

------
ggchappell
> I think we should call them "generator comprehensions" again.

I think we already do. Perhaps not _officially_ , but "generator
comprehension" is a widely used term among Python folks, in my experience.

A quick Google offers no evidence to the contrary:
[https://encrypted.google.com/search?q=python%20%22generator%...](https://encrypted.google.com/search?q=python%20%22generator%20comprehension%22)

------
erubin
is the difference between a generator and the rest that generators are lazy?

~~~
ubernostrum
Superficially that's a common difference that will be noticed.

The thing that sets generators apart from other iterable types in Python,
though, is actually the fact that generators are units of code which can
suspend their execution, then resume it at a later time (and in more recent
versions of Python, can have additional information passed into them while
doing so).

Formally, a generator is a callable whose body contains at least one yield
expression. So for example when you pull the values out of it (the way you
would with an ordinary iterable) what happens is that it executes until it
encounters a yield, emits whatever value is specified by the yield, and
suspends execution. The next time it's asked for a value, it resumes execution
until it encounters a yield again. You can continue in this way until either
1) the generator executes a 'return' statement, or 2) control flows past the
end of the generator's code, or 3) the generator raises a StopIteration
exception (and in the first two cases a StopIteration gets raised for you by
Python, so that you don't have to explicitly do it if you don't want to).

This means generators can be used to implement lazy iterables, infinite
iterables, etc., but also means generators can be used as coroutines by taking
advantage of their ability to suspend/resume and pass control flow around.

