[issue24056] Expose closure & generator status in function repr()

Nick Coghlan added the comment: I don't think we should rush this one, especially as PEP 484 provides the possibility for tools (including educational tools) to infer the appropriate return types for generator and coroutine functions. Bumping the target version to 3.6 accordingly. --

[issue24056] Expose closure & generator status in function repr()

Raymond Hettinger added the comment: > 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 hug

[issue24056] Expose closure & generator status in function repr()

Serhiy Storchaka added the comment: I like the look of the repr Terry proposes better. For generator objects the repr is either "" or "". "" and "" would be consistent with this. It also shows the relation and the difference between the generator function and the generator object. Yet one ar

[issue24056] Expose closure & generator status in function repr()

Berker Peksag added the comment: I'm not the ideal candidate to review the second patch since I'm not familiar with the best practices of C :) -- nosy: +serhiy.storchaka ___ Python tracker

[issue24056] Expose closure & generator status in function repr()

Yury Selivanov added the comment: Nick, Berker, a kind reminder -- please review the patch if we want to have it in 3.5. -- ___ Python tracker ___ __

[issue24056] Expose closure & generator status in function repr()

Changes by Yury Selivanov : Added file: http://bugs.python.org/file39461/issue24056_2.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24056] Expose closure & generator status in function repr()

Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39460/issue24056_2.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue24056] Expose closure & generator status in function repr()

Yury Selivanov added the comment: Nick, Berker, please find an updated patch attached (with support for coroutines). Big +1 on the idea, BTW. -- Added file: http://bugs.python.org/file39460/issue24056_2.diff ___ Python tracker

[issue24056] Expose closure & generator status in function repr()

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue24056] Expose closure & generator status in function repr()

R. David Murray added the comment: Although I like the look of the repr Terry proposes better, I agree with Nick: it would imply that the types were distinct, which they are not. -- nosy: +r.david.murray ___ Python tracker

[issue24056] Expose closure & generator status in function repr()

Nick Coghlan added the comment: The main reason I suggest using the postfix parenthetical syntax is to make it clear that we're exposing "behavioural feature flags" for a single underlying type. A prefix syntax would make them look like distinct types, which would be misleading in a different way

[issue24056] Expose closure & generator status in function repr()

Terry J. Reedy added the comment: Describing generator functions as such is a great idea. But how about Marking closure functions as such is a bit more subtle. However, there ia a real point that closure functions have a hidden input. If it is mutated or rebound, the function will not b

[issue24056] Expose closure & generator status in function repr()

Nick Coghlan added the comment: It's mostly pedagogical - similar to "normal functions" vs "generator functions", folks talk about functions and closures as different things, even though in Python a closure is just a normal function with one or more references to cells that were defined in out

[issue24056] Expose closure & generator status in function repr()

Mark Dickinson added the comment: I can see that the `generator` information would be useful. What's the use-case for reporting that a function is a closure? I'm having trouble thinking of a case where it's useful to know that a function is a closure without also knowing which locals refer t

[issue24056] Expose closure & generator status in function repr()

Berker Peksag added the comment: Here is a patch with a test. -- components: +Interpreter Core keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review Added file: http://bugs.python.org/file39224/issue24056.diff ___ Python tracker

[issue24056] Expose closure & generator status in function repr()

Changes by Petr Viktorin : -- nosy: +encukou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24056] Expose closure & generator status in function repr()

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue24056] Expose closure & generator status in function repr()

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue24056] Expose closure & generator status in function repr()

Changes by Nick Coghlan : -- stage: -> needs patch type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue24056] Expose closure & generator status in function repr()

New submission from Nick Coghlan: >From https://mail.python.org/pipermail/python-ideas/2015-April/033177.html, >there are some additional details about functions that could be usefully >exposed in the function repr, specifically whether or not it's a closure, and >whether or not it's a generat