This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Arfrever, berker.peksag, ethan.furman, mark.dickinson, ncoghlan, petr.viktorin, r.david.murray, rhettinger, serhiy.storchaka, terry.reedy, yselivanov
Date 2015-05-22.22:34:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> It's mostly pedagogical - similar to "normal functions" 
> vs "generator functions",

I see a need for this but object to calling it a "generator" rather than a "function that makes a generator" or "generator creating function" or somesuch.  There is a huge semantic difference between the two.

Another thought this that I'm not sure that a __repr__ should try usurp something that is the primary responsibility of a docstring or function annotation here.  Whether a function call runs code and returns a value or whether it returns a generator is fundamental to what the function does.  The usual job of the __repr__ is to tell what the object is.  The usual job of a docstring or type annotation to the describe what is returned.

> Marking closure functions as such is a bit more subtle.
> However, there ia a real point that closure functions 
> have a hidden input.

I don't see a need for this and think it make cause more confusion than help.  I try to teach that callables are all conceptually the same thing (something that has a __call__ method).  It matters very little whether a callable is implemented as a closure or using a class with a __call__ method.

So, put me down for -1 on this one.
Date User Action Args
2015-05-22 22:34:00rhettingersetrecipients: + rhettinger, terry.reedy, mark.dickinson, ncoghlan, Arfrever, r.david.murray, petr.viktorin, ethan.furman, berker.peksag, serhiy.storchaka, yselivanov
2015-05-22 22:34:00rhettingersetmessageid: <>
2015-05-22 22:34:00rhettingerlinkissue24056 messages
2015-05-22 22:34:00rhettingercreate