Terry Reedy udel.edu> writes:
> tout court?? is not English or commonly used at least in America
It is French:
http://encarta.msn.com/dictionary_561508877/tout_court.html
I thought it was common in English too, but clearly I was mistaken.
> Ok, you mean generator function, which produces gene
Phillip J. Eby telecommunity.com> writes:
> I think the whole concept of inspecting for this is broken. *Any*
> function can return a generator-iterator. A generator function is just a
> function that happens to always return one.
> In other words, the confusion is in the idea of introspectin
Phillip J. Eby writes:
> Yes, I think the whole concept of inspecting for this is broken.
> *Any* function can return a generator-iterator. A generator
> function is just a function that happens to always return one.
Just following up on Phillip's comments, consider the following functions:
At 09:26 AM 6/1/2006 +, Michele Simionato wrote:
>Terry Reedy udel.edu> writes:
> > To me, another obvious way is isinstance(object, gentype) where
> > gentype = type(i for i in []) # for instance
> > which should also be in types module.
>
>No, that check would match generator objects, not ge
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yep, this is the crux. types.GeneratorType refers to generator objects,
> which in an improper sense are "instances" of a "generator function".
> I.e.
>
> def g(): yield 1 # this is a generator
>
> go = g() # this
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> No, that check would match generator objects, not generators tout court.
tout court?? is not English or commonly used at least in America
> On a related notes, inspect.isfunction gives True on a generator, such
>
Michele Simionato wrote:
> Georg Brandl gmx.net> writes:
>>
>> > Also, should one add
>> > a GeneratorType, perhaps as a subclass of FunctionType?
>>
>> Add GeneratorType where? There is already one in the types module.
>
> Yep, this is the crux. types.GeneratorType refers to generator objects,
Georg Brandl gmx.net> writes:
>
> > Also, should one add
> > a GeneratorType, perhaps as a subclass of FunctionType?
>
> Add GeneratorType where? There is already one in the types module.
Yep, this is the crux. types.GeneratorType refers to generator objects,
which in an improper sense are "ins
Michele Simionato wrote:
> Georg Brandl gmx.net> writes:
>
>> I'd say, go ahead and write a patch including docs, and I think there's no
>> problem with accepting it (as long as it comes before beta1).
>
> I was having a look at http://docs.python.org/dev/lib/inspect-types.html
> and it would se
Georg Brandl gmx.net> writes:
> I'd say, go ahead and write a patch including docs, and I think there's no
> problem with accepting it (as long as it comes before beta1).
I was having a look at http://docs.python.org/dev/lib/inspect-types.html
and it would seem that adding isgenerator would impl
Terry Reedy udel.edu> writes:
> To me, another obvious way is isinstance(object, gentype) where
> gentype = type(i for i in []) # for instance
> which should also be in types module.
No, that check would match generator objects, not generators tout court.
On a related notes, inspect.isfunction gi
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Neal Norwitz gmail.com> writes:
>>
>> > I wonder whether a check shouldn't just return (co_flags & 0x20),
>> > which
>> > is CO_GENERATOR.
>>
>> Makes more sense.
>
> Okay, but my point is that the final user shou
Michele Simionato wrote:
> Neal Norwitz gmail.com> writes:
>>
>> > I wonder whether a check shouldn't just return (co_flags & 0x20), which
>> > is CO_GENERATOR.
>>
>> Makes more sense.
>
> Okay, but my point is that the final user should not be expected to know
> about those implementation deta
Neal Norwitz gmail.com> writes:
>
> > I wonder whether a check shouldn't just return (co_flags & 0x20), which
> > is CO_GENERATOR.
>
> Makes more sense.
Okay, but my point is that the final user should not be expected to know
about those implementation details. The one obvious way to me is to h
On 5/29/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> >
> > is there some natural and obvious connection between generators and that
> > number that I'm missing, or is that constant perhaps best hidden inside
> > some introspection support module?
>
> It seems to be a combina
Fredrik Lundh wrote:
> Terry Reedy wrote:
>
>>> def isgenerator(func):
>>>return func.func_code.co_flags == 99
>>>
>>> but it is rather ugly (horrible indeed).
>>
>> To me, part of the beauty of Python is that is so easy to write such things
>> so compactly, so that we do not need megaAPIs w
Terry Reedy wrote:
>> def isgenerator(func):
>>return func.func_code.co_flags == 99
>>
>> but it is rather ugly (horrible indeed).
>
> To me, part of the beauty of Python is that is so easy to write such things
> so compactly, so that we do not need megaAPIs with hundreds of functions
> and
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Is there still time for new feature requests in Python 2.5?
> I am missing a isgenerator function in the inspect module. Right now
> I am using
>
> def isgenerator(func):
>return func.func_code.co_flags == 99
>
18 matches
Mail list logo
