Nick Coghlan wrote:
1. Applies only if you are making large slices, or a lot of slices with
each containing at least 3 elements.
A view can also *cost* memory, when it looks at a small piece of a
large item. The view will keep the entire item alive, even though it
needs only a small piece.
Tha
"Bengt Richter" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> On Wed, 26 Jan 2005 11:55:59 -0800, jfj <[EMAIL PROTECTED]> wrote:
>
> >Jeff Shannon wrote:
> >
> >>
> >>
> >> So, what problem is it, exactly, that you think you'd solve by making
> >> tuple slices a view rather than a c
jfj wrote:
Actually, i think that slices with step, is a bad feature in general
and i think I will write a PEP to suggest their removal in python3k.
I wouldn't bother. Extended slicing was added to support those doing serious
numerical work in Python, and it won't get removed for all the reasons i
jfj wrote:
Jeff Shannon wrote:
So, what problem is it, exactly, that you think you'd solve by making
tuple slices a view rather than a copy?
I think views are good for
1) saving memory
2) saving time (as you don't have to copy the elements into the new tuple)
1. Applies only if you are making
On Wed, 26 Jan 2005 11:55:59 -0800, jfj <[EMAIL PROTECTED]> wrote:
>Jeff Shannon wrote:
>
>>
>>
>> So, what problem is it, exactly, that you think you'd solve by making
>> tuple slices a view rather than a copy?
>>
>
>I think views are good for
> 1) saving memory
> 2) saving time (as you don
On Tue, 25 Jan 2005 19:25:55 -0500, "George Sakkis" <[EMAIL PROTECTED]> wrote:
>"Jeff Shannon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>> George Sakkis wrote:
>>
>> > An iterator is perfectly ok if all you want is to iterate over the
>> > elements of a view, but as you noted, i
Jeff Shannon wrote:
So, what problem is it, exactly, that you think you'd solve by making
tuple slices a view rather than a copy?
I think views are good for
1) saving memory
2) saving time (as you don't have to copy the elements into the new tuple)
And they are worth it. However, (as in other
"Jeff Shannon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> George Sakkis wrote:
>
> > An iterator is perfectly ok if all you want is to iterate over the
> > elements of a view, but as you noted, iterators are less flexible than
> > the underlying sequence. The view should be (or a
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:mailman.1308.1106688018.22381.python-
>
> Unless you are GvR or Tim Peters,
Actually I am the OP. I posted my previous mail from Google groups, which for
some reason put my
email instead of my name; it should be ok now.
> throwing 'pythoni
George Sakkis wrote:
An iterator is perfectly ok if all you want is to iterate over the
elements of a view, but as you noted, iterators are less flexible than
the underlying sequence. The view should be (or at least appear)
identical in functionality (i.e. public methods) with its underlying
sequen
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Terry Reedy wrote:
>> In other words, if you don't really want slices copied out of the
>> sequence,
>> then don't slice! Just use 2 ints to indicate the working region or
>> view.
>> Both this and using a nested function with add
An iterator is perfectly ok if all you want is to iterate over the
elements of a view, but as you noted, iterators are less flexible than
the underlying sequence. The view should be (or at least appear)
identical in functionality (i.e. public methods) with its underlying
sequence.
George
--
http
Terry Reedy wrote:
> "George Sakkis" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Actually my initial motivation was not a huge tuple I had to slice
many
> > times. It was something much
> > less extraordinarily unlikely, a recursive function with a sequence
> > parameter:
>
George Sakkis wrote:
You're probably right about the allocation time, but my main concern is the
memory required for each
slice, which can be O(n) wrt the length of the whole tuple. I would like this
to be constant (at
least if there was a way around to the problem of deleting the underlying
seq
"George Sakkis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Actually my initial motivation was not a huge tuple I had to slice many
> times. It was something much
> less extraordinarily unlikely, a recursive function with a sequence
> parameter:
>
> def foo(sequence):
># b
"Jeff Shannon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> [My newsreader crapped out on sending this; apologies if it appears
> twice.]
>
> George Sakkis wrote:
>
> > "Terry Reedy" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >
> >>Aside from the problem of
[My newsreader crapped out on sending this; apologies if it appears
twice.]
George Sakkis wrote:
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Aside from the problem of not being able to delete the underlying object,
the view object for a tuple would have to be a new t
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Aside from the problem of not being able to delete the underlying object,
> the view object for a tuple would have to be a new type of object with a
> new set of methods.
It *could*, but it doesn't have to. One can repre
"Peter Hansen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> George Sakkis wrote:
> > Fair enough. So perhaps the question is whether such cases are more regular
> > than something like:
> > a = give_me_a_huge_tuple()
> > slices = [a[i:j] for i in xrange(len(a)) for j in xrange(i+1
"George Sakkis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Why does slicing a tuple returns a new tuple instead of a
> view of the existing one, given that
> tuples are immutable ? I ended up writing a custom
> ImmutableSequence class that does this, but I
> wonder why it is no
George Sakkis wrote:
Fair enough. So perhaps the question is whether such cases are more regular
than something like:
a = give_me_a_huge_tuple()
slices = [a[i:j] for i in xrange(len(a)) for j in xrange(i+1, len(a)+1)]
I believe the general usage of tuples tends to mean that
"give_me_a_huge_tuple()
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Steven Bethard wrote:
>
> >a = 1, 2, 3
> >b = a[:]
> >a is b
> >> True
> >
> > My impression was that full tuple copies didn't actually copy, but that
> > slicing a subset of a
> > tuple might. Not exactly
The cpython implementation stores tuples in memory like this:
[common fields for all Python objects]
[common fields for all variable-size python objects, including tuple size]
[fields specific to tuple objects, if any]
[array of PyObject*, one for each item in the tuple]
This way of
Fredrik Lundh wrote:
Steven Bethard wrote:
My impression was that full tuple copies didn't actually copy, but that slicing a subset of a
tuple might. Not exactly sure how to test this, but:
py> a = 1, 2, 3
py> a[:2] is a[:2]
False
yup. and to figure out why things are done this way, consider th
Steven Bethard wrote:
>a = 1, 2, 3
>b = a[:]
>a is b
>> True
>
> My impression was that full tuple copies didn't actually copy, but that
> slicing a subset of a
> tuple might. Not exactly sure how to test this, but:
>
> py> a = 1, 2, 3
> py> a[:2] is a[:2]
> False
yup. and to figu
On Mon, 24 Jan 2005 18:45:46 +0100
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
>
> > Why does slicing a tuple returns a new tuple instead of a view of
> > the existing one, given that tuples are immutable ?
>
> really?
Well... seems like this case (slicing the whole tuple
On Mon, 24 Jan 2005 18:45:46 +0100
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
>
> > Why does slicing a tuple returns a new tuple instead of a view of
> > the existing one, given that tuples are immutable ?
>
> really?
Well... seems like this case is optimized to return th
Fredrik Lundh wrote:
George Sakkis wrote:
Why does slicing a tuple returns a new tuple instead of a view of the existing
one, given that
tuples are immutable ?
really?
a = 1, 2, 3
b = a[:]
a is b
True
My impression was that full tuple copies didn't actually copy, but that
slicing a subset of a t
George Sakkis wrote:
> Why does slicing a tuple returns a new tuple instead of a view of the
> existing one, given that
> tuples are immutable ?
really?
>>> a = 1, 2, 3
>>> b = a[:]
>>> a is b
True
--
http://mail.python.org/mailman/listinfo/python-list
Title: RE: Tuple slices
[George Sakkis]
#- Why does slicing a tuple returns a new tuple instead of a
#- view of the existing one, given that
#- tuples are immutable ? I ended up writing a custom
#- ImmutableSequence class that does this, but I
#- wonder why it is not implemented for
30 matches
Mail list logo
