Re: non-copy slices
Tim Golden
> 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.
I suspect that itertools is your friend, specifically itertools.islice
TJG
Terry Reedy
> 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
> 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
Ethan Furman
> 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
> that all slice needs have strictly copy semantics.
>
> Themis
Two questions: 1) What is "sth"? and 2), What copy?
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
In [1]: class dummy(object):
...: pass
...:
In [2]: a = dummy()
In [3]: b = dummy()
In [4]: c = dummy()
In [5]: d = dummy()
In [6]: e = dummy()
In [7]: list1 = [a, b, c, d, e]
In [8]: list1
Out[8]:
[<__main__.dummy object at 0x0130C510>,
<__main__.dummy object at 0x013F1A50>,
<__main__.dummy object at 0x00A854F0>,
<__main__.dummy object at 0x00A7EF50>,
<__main__.dummy object at 0x00A7E650>]
In [9]: list2 = list1[1:3]
In [10]: list2
Out[10]:
[<__main__.dummy object at 0x013F1A50>,
<__main__.dummy object at 0x00A854F0>]
In [11]: list2[0] is list1[1]
Out[11]: *True*
In [12]: list2[1] is list1[2]
Out[12]: *True*
No copying of items going on here. What do you get?
~Ethan~
Rami Chowdhury
> Hi,
>
> sth == something :) sorry for the abbreviation. I'm talking about the
> shallow copy, still it's a copy.
I'm not sure you're understanding the point others have been making. A
list item is merely another reference to an existing object -- it
doesn't copy the object in any way.
> Unnecessary in my case and the worst
> part in my scenario is the creation (allocation)> and deletion of a
> very large number of lists of moderate size (a few hundred objects)
> generated due to slices, while I only need to have a restricted view
> on the original list.
> The islice class partially solves the problem
> as I mentioned in the previous emails.
>
> Cheers,
> Themis
>
> On Wed, Nov 18, 2009 at 3:44 PM, Ethan Furman <et...@stoneleaf.us>
wrote:
> > --
> > http://mail.python.org/mailman/listinfo/python-list
>
----
Rami Chowdhury
"As an online discussion grows longer, the probability of a comparison
involving Nazis or Hitler approaches one." -- Godwin's Law
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
Ethan Furman
tbou...@doc.ic.ac.uk wrote:
> On Thu, Nov 19, 2009 at 3:00 AM, Rami Chowdhury
> <rami.ch...@gmail.com <mailto:rami.ch...@gmail.com>> wrote:
>
> I'm not sure you're understanding the point others have been making. A
> list item is merely another reference to an existing object -- it
> doesn't copy the object in any way.
>
> No I'm well aware that there is no deep copy of the objects and the
> lists only keep references to the objects and in essence they have the
> same objects in there. But this doesn't mean they are the same list.
> Modifications to slices are not written back to the original list.
>
> x = range(5)
> y = x[1:3]
> y[0] = 13
> x[1] == y[0] --> False
>
> Of course if I modify the object in the slice then the original list
> will see the change, but this is not what I was saying. Second and more
> importantly it's the performance penalty from allocating a large number
> of lists produced from the slices and the copy of the references. islice
> does not have this penalty, it should only instantiate a small object
> that iterates on the original list.
>
> Themis
So "shallow copy" == "new label created for existing object".
So is your desired behavior to write back to the original list if your
sub-list is modified? In other words, you are creating a window onto an
existing list? If not, what would happen when a sublist element was
modified (or deleted, or appended, or ...)?
~Ethan~
Rami Chowdhury
> Second and more
> importantly it's the performance penalty from allocating a large number
> of
> lists produced from the slices and the copy of the references.
Ah, I see what you were getting at -- thanks for clarifying.
>
> On Thu, Nov 19, 2009 at 3:00 AM, Rami Chowdhury
> <rami.ch...@gmail.com>wrote:
>
>>
>> I'm not sure you're understanding the point others have been making. A
>> list item is merely another reference to an existing object -- it
>> doesn't copy the object in any way.
>>
>>
--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
Ethan Furman
> On Thu, Nov 19, 2009 at 2:44 PM, Ethan Furman <et...@stoneleaf.us
> <mailto:et...@stoneleaf.us>> wrote:
>
> So "shallow copy" == "new label created for existing object".
>
> So is your desired behavior to write back to the original list if your
> sub-list is modified? In other words, you are creating a window onto an
> existing list? If not, what would happen when a sublist element was
> modified (or deleted, or appended, or ...)?
>
> ~Ethan~
>
> modification you make in this view is actually modifying the original
> list accordingly. Blist that was suggested in a previous email in the
> thread seems lightweight but it does create a new list when a
> modification is made. In any case, I've already implemented the object
> myself and I can post it if you care to have a look, but I was just
> wondering if there was already something in the standard library.
>
> Themis
Unfortunately, I am not very familiar with the stdlib yet (gotta buy
that book!). I'm going to guess 'No' since nobody has chimed in with a
'Yes', though.
I'd love to see what you have for that. Does in support a stepped
window, or only contiguous sequences? The one I put together this
afternoon only does contiguous sequences, as I had no use cases to
decide how assignments of multiple items should be handled, and not a
lot of time to implement something generic -- so, to answer John's
question from a completely different thread, yes I do enjoy working on
small projects even if IAGNI. :)
Cheers!
~Ethan~
Ajit Kumar
>> No I'm well aware that there is no deep copy of the objects and the lists
>> only keep references to the objects and in essence they have the same
>> objects in there. But this doesn't mean they are the same list.
>> Modifications to slices are not written back to the original list.
>>
>> x = range(5)
>> y = x[1:3]
>> y[0] = 13
>> x[1] == y[0] --> False
>>
>> Of course if I modify the object in the slice then the original list will
>> importantly it's the performance penalty from allocating a large number of
>> not have this penalty, it should only instantiate a small object that
>> iterates on the original list.
>>
>> Themis
>
>
> So is your desired behavior to write back to the original list if your
> sub-list is modified? In other words, you are creating a window onto an
> existing list? If not, what would happen when a sublist element was
> modified (or deleted, or appended, or ...)?
On a related note, GO encourages use of slices.