t.bourdenas07 at imperial.ac.uk
Wed Nov 18 21:22:11 CET 2009
Sth else that I noticed as I started using islice. The name is somewhat
misleading. Having the slice part in the name I would expect it to imitate
the functionality of normal slices. Random access, sub-slicing etc. However,
it is only iteratable. Any particular reasons for that? My guess is that
it's inside the itertools so it's meant only for iteration and not random
access. However, as I told before the name implies the same functionality
while the only thing they share is iteration. It's nothing in the library
that completely imitates the slice without the copies, right?
On Wed, Nov 18, 2009 at 6:49 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> tbourden at doc.ic.ac.uk wrote:
> > Hi,
> > I was looking for a facility similar to slices in python library that
> > would avoid the implicit creation of a new list and copy of elements
> > that is the default behaviour. Instead I'd rather have a lazy iteratable
> > object on the original sequence. Well, in the end I wrote it myself but
> > I was wondering if I missed sth in the library If I didn't is there a
> > particular reason there isn't sth like that? I find it hard to believe
> > that all slice needs have strictly copy semantics.
> It is a strict *shallow* copy. There is no copying of contents.
> That aside, you are right, hence itertools.islice as already mentioned.
> In the design of 3.0, I believe the idea was raised of making slices
> iterables in 3.0, just as was done for map, filter, and range. However,
> it would have been highly disruptive, and not save much space. Map and
> range create an unbounded number of new objects, rather than just a
> sequence of references to existing objects (or bytes or words for bytes
> and str slices). There is also the problem of virtual slices preventing
> garbage collection of the source sequence when it is not otherwise needed.
> Terry Jan Reedy
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list