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:
- 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?)
- 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
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:
- 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?)
- 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