[issue15457] consistent treatment of generator terminology

Cheryl Sabella added the comment: Issue24400 changed some of the documentation wording around generators. I don't know if there is still interest in applying the other parts of this patch. -- nosy: +cheryl.sabella versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.3, Python 3.4

[issue15457] consistent treatment of generator terminology

Changes by Terry J. Reedy : -- versions: +Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15457] consistent treatment of generator terminology

Chris Jerdonek added the comment: This slipped under my radar. After starting work on this again, I realize that it would make sense to complete issue 15476 first. The reason is that it would improve the process of referencing "code object" in the generator docs (Terry's suggestion) once "co

[issue15457] consistent treatment of generator terminology

Chris Jerdonek added the comment: Note to reviewers: changing to "needs patch" because I want to make changes to the latest patch before this is reviewed (e.g. to the index directives). I should be able to do this by the end of the weekend. -- stage: -> needs patch

[issue15457] consistent treatment of generator terminology

Chris Jerdonek added the comment: I created issue 15476 to add "code object" to the glossary. > Generator functions must have a special __call__ method that simply creates > and returns a generator instance with the code object attached (instead of > executing the code). Just to be sure, is

[issue15457] consistent treatment of generator terminology

Terry J. Reedy added the comment: I will try to read your new patch when I am fresher. -- ___ Python tracker ___ ___ Python-bugs-list

[issue15457] consistent treatment of generator terminology

Terry J. Reedy added the comment: Up until today, I had assumed that it was the generator.__next__ method that was associated with the compiled body. But in writing my response, I investigated and discovered >>> def gf(): yield None >>> gf().gi_code is gf.__code__ True Then i realized that

[issue15457] consistent treatment of generator terminology

Chris Jerdonek added the comment: Attaching updated patch incorporating feedback. It would be nice to have a good term for "the generator function code object associated with a generator" to distinguish it from the original generator function as you point out. There are many places in the do

[issue15457] consistent treatment of generator terminology

Chris Jerdonek added the comment: Thanks a lot for the excellent feedback. I'll update the patch to incorporate it. One background note: I tried not to be too strict about using "generator iterator" or "generator function" in place of "generator" in the general docs in deference to this rem

[issue15457] consistent treatment of generator terminology

Terry J. Reedy added the comment: I think the current entry calling a generator function a generator is wrong, so I appreciate your patch. Generator functions return instances of class 'generator'*. I personally refer to generators as generator-iterators about as often as I refer to lists as

[issue15457] consistent treatment of generator terminology

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue15457] consistent treatment of generator terminology

Chris Jerdonek added the comment: Attaching patch. -- keywords: +patch Added file: http://bugs.python.org/file26526/issue-15457-1.patch ___ Python tracker ___ __

[issue15457] consistent treatment of generator terminology

New submission from Chris Jerdonek : The documentation on generators (outside of PEP 255) does not currently educate the reader on the more specific "generator function" and "generator iterator" terminology, or at least not in any consistent or systematic way. For example, the glossary includ