Python Generator comprehensions | Hacker News Reader

Python Generator comprehensions

nedbatchelder.com

21 pointsingve5 comments

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/

> 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%...

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

  Yes.

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.

Reply on news.ycombinator.com