I have 2 related proposals: 1. Give generators a .__name__ attribute that is the same as their curent (3.0a5) .gi_code.co_name subattribute. just as funct.__name__ is func.__code__.co_name. My reason is, I expect, much the same as that for func.__name__. I am using the generator name (for bad-iterator-output messages in a test function) and would prefer to get it through a cross-implementation 'public' interface' rather than a cPython internal implementation detail (which I understand code object to be). I am otherwise trying to avoid using cPython internals. (Is there any plan to change the gi_* attributes the way the func_* attributes were?) 2. Whether or not 1 is adopted, add the name to the representation: <gfuncname generator object as..> or <generator object gfuncname at ..> Conceptually, I see a generator function as an abbreviated version of a iterator class, with most of the boilerplate removed, that defines a subclass of the generator class. So I think the subclass name should be part of its representation. Terry Jan Reedy
Sounds fine with me. Have you cooked up a patch yet so we can see how complex the change is, whether it breaks anything, etc.? On Wed, May 14, 2008 at 11:36 PM, Terry Reedy <tjreedy@udel.edu> wrote:
I have 2 related proposals:
1. Give generators a .__name__ attribute that is the same as their curent (3.0a5) .gi_code.co_name subattribute. just as funct.__name__ is func.__code__.co_name.
My reason is, I expect, much the same as that for func.__name__. I am using the generator name (for bad-iterator-output messages in a test function) and would prefer to get it through a cross-implementation 'public' interface' rather than a cPython internal implementation detail (which I understand code object to be). I am otherwise trying to avoid using cPython internals.
(Is there any plan to change the gi_* attributes the way the func_* attributes were?)
2. Whether or not 1 is adopted, add the name to the representation: <gfuncname generator object as..> or <generator object gfuncname at ..>
Conceptually, I see a generator function as an abbreviated version of a iterator class, with most of the boilerplate removed, that defines a subclass of the generator class. So I think the subclass name should be part of its representation.
Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
A patch suggestion is at <http://bugs.python.org/issue2863>. Georg Guido van Rossum schrieb:
Sounds fine with me. Have you cooked up a patch yet so we can see how complex the change is, whether it breaks anything, etc.?
On Wed, May 14, 2008 at 11:36 PM, Terry Reedy <tjreedy@udel.edu> wrote:
I have 2 related proposals:
1. Give generators a .__name__ attribute that is the same as their curent (3.0a5) .gi_code.co_name subattribute. just as funct.__name__ is func.__code__.co_name.
My reason is, I expect, much the same as that for func.__name__. I am using the generator name (for bad-iterator-output messages in a test function) and would prefer to get it through a cross-implementation 'public' interface' rather than a cPython internal implementation detail (which I understand code object to be). I am otherwise trying to avoid using cPython internals.
(Is there any plan to change the gi_* attributes the way the func_* attributes were?)
2. Whether or not 1 is adopted, add the name to the representation: <gfuncname generator object as..> or <generator object gfuncname at ..>
Conceptually, I see a generator function as an abbreviated version of a iterator class, with most of the boilerplate removed, that defines a subclass of the generator class. So I think the subclass name should be part of its representation.
Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
participants (3)
-
Georg Brandl -
Guido van Rossum -
Terry Reedy