Guido van Rossum wrote:
Iterators are for single sequential access. It's a feature that you
have to import itertools (or at least that you have to invoke its
special operations) -- iterators are not sequences and shouldn't be
confused with such.
I agree the semantic difference between an iterable a
Steven Bethard wrote:
If we're really looking for a builtin, wouldn't it be better to go the
route of getattr/setattr and have something like getslice that could
operate on both lists and iterators?
Such a builtin should probably be getitem() rather than getslice() (since
getitem(iterable, slice(s
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> FWIW, someone (Bengt Richter perhaps) once suggested syntactic support
> differentiated from sequences but less awkward than a call to
> itertools.islice().
>
> itertools.islice(someseq, lo, hi) would be rendered as someseq'[lo:hi].
Just to make s
> Iterators are for single sequential access. It's a feature that you
> have to import itertools (or at least that you have to invoke its
> special operations) -- iterators are not sequences and shouldn't be
> confused with such.
FWIW, someone (Bengt Richter perhaps) once suggested syntactic suppo
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Since we already have the islice iterator, what's the point?
>
> I'd like to see iterators become as easy to work with as lists are. At the
> moment, anything that returns an iterator forces you to use the relatively
> cumber
Nick Coghlan wrote:
> In the example below (printing the first 3 items of a sequence), the fact that
> sorted() produces a new iterable list, while reversed() produces an iterator
> over the original list *should* be an irrelevant implementation detail from
> the
> programmer's point of view.
You
[me]
> > Since we already have the islice iterator, what's the point?
[Nick]
> I'd like to see iterators become as easy to work with as lists are. At the
> moment, anything that returns an iterator forces you to use the relatively
> cumbersome itertools.islice mechanism, rather than Python's nativ
Batista, Facundo wrote:
I think that breaking the common idiom...
for e in something[:]:
something.remove(e)
is a no-no...
The patch doesn't change existing behaviour - anything which is already
sliceable (e.g. lists) goes through the existing __getitem__ or __getslice__
code paths.
All
Guido van Rossum wrote:
Since we already have the islice iterator, what's the point?
I'd like to see iterators become as easy to work with as lists are. At the
moment, anything that returns an iterator forces you to use the relatively
cumbersome itertools.islice mechanism, rather than Python's na
Title: RE: [Python-Dev] Allowing slicing of iterators
[Guido van Rossum]
#- > As a trivial example, here's how to skip the head of a
#- zero-numbered list:
#- >
#- > for i, item in enumerate("ABCDEF")[1:]:
#- > print i, item
#- >
#- > Is this idea
> I just wrote a new C API function (PyItem_GetItem) that supports slicing for
> arbitrary iterators. A patch for current CVS is at
> http://www.python.org/sf/1108272
>
> For simple indices it does the iteration manually, and for extended slices it
> returns an itertools.islice object.
>
> As a
I just wrote a new C API function (PyItem_GetItem) that supports slicing for
arbitrary iterators. A patch for current CVS is at http://www.python.org/sf/1108272
For simple indices it does the iteration manually, and for extended slices it
returns an itertools.islice object.
As a trivial example
12 matches
Mail list logo
