George Sakkis wrote:
> Carl Banks wrote:
> > George Sakkis wrote:
> > > If by 'respond to "+"' is implied that you can get a "TypeError:
> > > iterable argument required", as you get now for attempting "x in y" for
> > > non-iterable y, why not ?
> >
> > Bad idea on many, many levels. Don't go th
Carl Banks wrote:
> Georg Brandl wrote:
>> What has a better chance of success in my eyes is an extension to yield
>> all items from an iterable without using an explicit for loop: instead of
>>
>> for item in iterable:
>> yield item
>>
>> you could write
>>
>> yield from iterable
>>
>> or
>>
Carl Banks wrote:
> George Sakkis wrote:
> > Fredrik Lundh wrote:
> >
> > > George Sakkis wrote:
> > >
> > > > The base object class would be one candidate, similarly to the way
> > > > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> > > >
> > > > Alternatively, iter() co
George Sakkis wrote:
> Fredrik Lundh wrote:
>
> > George Sakkis wrote:
> >
> > > The base object class would be one candidate, similarly to the way
> > > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> > >
> > > Alternatively, iter() could be a wrapper type (or perhaps mix
Georg Brandl wrote:
> What has a better chance of success in my eyes is an extension to yield
> all items from an iterable without using an explicit for loop: instead of
>
> for item in iterable:
> yield item
>
> you could write
>
> yield from iterable
>
> or
>
> yield *iterable
Since this is
Fredrik Lundh wrote:
> George Sakkis wrote:
>
> > The base object class would be one candidate, similarly to the way
> > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> >
> > Alternatively, iter() could be a wrapper type (or perhaps mixin)
> > instead of a function, somet
George Sakkis wrote:
> Fredrik Lundh wrote:
>
>> John Reese wrote:
>>
>> > It seems like it would be clear and mostly backwards compatible if the
>> > + operator on any iterables created a new iterable that iterated
>> > throught first its left operand and then its right, in the style of
>> > iter
George Sakkis wrote:
> The base object class would be one candidate, similarly to the way
> __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
>
> Alternatively, iter() could be a wrapper type (or perhaps mixin)
> instead of a function, something like:
so you're proposing to
Fredrik Lundh wrote:
> John Reese wrote:
>
> > It seems like it would be clear and mostly backwards compatible if the
> > + operator on any iterables created a new iterable that iterated
> > throught first its left operand and then its right, in the style of
> > itertools.chain.
>
> you do know th
John Reese wrote:
> It seems like it would be clear and mostly backwards compatible if the
> + operator on any iterables created a new iterable that iterated
> throught first its left operand and then its right, in the style of
> itertools.chain.
you do know that "iterable" is an informal interf
It seems like it would be clear and mostly backwards compatible if the
+ operator on any iterables created a new iterable that iterated
throught first its left operand and then its right, in the style of
itertools.chain. This would allow summation of generator expressions,
among other things, to h
11 matches
Mail list logo
