[Python-ideas] Integrate some itertools into the Python syntax

[Michel Desmoulin]

Le 23/03/2016 06:13, Nick Coghlan a écrit :
> On 22 March 2016 at 09:06, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
>> So my first proposal is to be able to do:
>>
>> def stop(element):
>>     return element > 4
>> print(numbers[:stop])
>>
>> It's quite pythonic, easy to understand : the end of the slice is when
>> this condition is met. Any not the strange way takewhile work, which is
>> "carry on as long as this condition is met".
>>
>> We could also extend itertools.islice to accept such parameter.
> 
> iter() already has a two-argument form to accept a callable+sentinel
> value, so it may not be unreasonable to offer an "until" callback to
> say when to stop iterating.
> 
> That is:
> 
>     def stop(element):
>         return element >4
>     print(list(iter(numbers, until=stop)))

Do you propose to make a "since" param too ?

> 
> Slicing arbitrary iterables may be amenable to a str.join style
> solution, by putting the functionality on slice objects, rather than
> on the iterables:
> 
>     slice(3, 7).iter(iterable)

Those solutions are already much more convenient than using itertools,
but it's going to look very strange:

def foo(p):
     with open(p) as f:
         def begin():
             return x.startswith('#')
         def end():
             return x != "STOP"
        yield from slice(0, 10).iter(iter(f, since=begin, until=en))

The last line is really not Pythonic.

Compared to:


def foo(p):
     with open(p) as f:
         def begin():
             return x.startswith('#')
         def end():
             return x != "STOP"
        yield from f[begin:end][:10]

But I beleive there is an idea here. Attaching things to slice is
cleaner than to iter():


def foo(p):
    with open(p) as f:
        def begin():
            return x.startswith('#')
        def end():
            return x != "STOP"

        yield from slice.wraps(f)[begin:end][:10]


> 
> (Whether or not to make slice notation usable outside subscript
> operations could then be tackled as an independent question)
> 
> For itertools.chain, it may make sense to simply promote it to the builtins.

Same problem as with new keywords : it can be a problem with people
using chain as a var name.

> 
> I'm not the least bit sure about the wisdom of the first two ideas,
> but the last one seems straightforward enough, and I'd be comfortable
> with us putting "chain" on the same tier as existing builtin iteration
> related tools like enumerate and zip.

To be fair, I don't nearly use chain as much as zip or enumerate, so I'm
not going to push for something as drastic.

> 
> Regards,
> Nick.
>