Ben C wrote:
I used to think it assigned with things like integers, because if you
write:
a = 5
b = a
b += 1
print a
a is still 5. So it looked like a and b stored values and b got a copy
of a's value. But this is the wrong interpretation,
b += 1
is really b = b
Dennis Lee Bieber [EMAIL PROTECTED] writes:
On Fri, 14 Apr 2006 09:17:05 +0400, Sergei Organov [EMAIL PROTECTED]
declaimed the following in comp.lang.python:
I, as a newcomer, don't have much trouble understanding the binding vs
the assignment by themselves. What does somewhat confuse is
On 2006-04-14, Sergei Organov [EMAIL PROTECTED] wrote:
Dennis Lee Bieber [EMAIL PROTECTED] writes:
It always means bind... But if the LHS is a mutable object, AND you
have specified a component of that object, it is the component that is
being rebound...
lst[:] = []
[...]
Me
Raymond, I suspect we're not seeing eye to eye on this issue, but I do
appreciate you taking the time and effort. Thank you. My comments follow.
On Thu, 13 Apr 2006
09:34:46 -0700, Raymond Hettinger wrote:
Both the pros and cons
were quipped with abrupt perjoratives so the bullet points could
Duncan Booth wrote:
Looking in the 'obvious' place in the Tutorial, section 5.1 'More on
Lists' I found in the immediately following section 5.2 'The del
statement':
I read the tutorial 6 years ago, and don't read it regularly. What's in
the tutorial is not really important, what can be
Peter Hansen wrote:
* learning slices is basic to the language (this lesson shouldn't be
skipped)
And yet it doesn't appear to be in the tutorial.
oh, please.
slices are explained in the section on strings, and in the section on lists,
and used to define the behaviour of the list methods
Peter Hansen wrote:
It's not even clear that extend needs two lines:
s = range(5)
more = list('abc')
s[:] = s + more
s
[0, 1, 2, 3, 4, 'a', 'b', 'c']
Okay, it's not obvious, but I don't think s[:]=[] is really any more
obvious as a way to clear the list.
Clearly .extend()
Peter Hansen wrote:
* learning slices is basic to the language (this lesson shouldn't be
skipped)
And yet it doesn't appear to be in the tutorial. I could have missed
it, but I've looked in a number of the obvious places, without
actually going through it (again) from start to finish.
Raymond Hettinger wrote:
Cons:
-
* learning slices is basic to the language (this lesson shouldn't be
skipped)
also, a clear method would simply clear the entire list. You still need to
learn the assigning to/deleting slices technique any time you want to clear
out part of a list.
Duncan Booth wrote:
Peter Hansen wrote:
* learning slices is basic to the language (this lesson shouldn't be
skipped)
And yet it doesn't appear to be in the tutorial. I could have missed
Both of these talk about ways to remove slices from a list. Perhaps the
wording could be clearer
On Thu, 13 Apr 2006 07:49:11 +, Duncan Booth wrote:
Raymond Hettinger wrote:
Cons:
-
* learning slices is basic to the language (this lesson shouldn't be
skipped)
also, a clear method would simply clear the entire list. You still need to
learn the assigning to/deleting
On Thu, 13 Apr 2006 09:11:31 +0200, Fredrik Lundh wrote:
Peter Hansen wrote:
It's not even clear that extend needs two lines:
s = range(5)
more = list('abc')
s[:] = s + more
s
[0, 1, 2, 3, 4, 'a', 'b', 'c']
Okay, it's not obvious, but I don't think s[:]=[] is really any more
Alan Morgan wrote:
Ah, but if you know your basic python then you wouldn't be looking for
s.clear() in the first place; you'd just use s[:]=[] (or s=[], whichever
is appropriate).
One of very first things newcomers learn (I believe, though I don't know
how soon the tutorial teaches it) is
Duncan Booth wrote:
Peter Hansen wrote:
Looking in the 'obvious' place in the Tutorial, section 5.1 'More on
Lists' I found in the immediately following section 5.2 'The del
statement':
There is a way to remove an item from a list given its index instead
of its value: the del statement.
Peter Hansen wrote:
One of very first things newcomers learn (I believe, though I don't know
how soon the tutorial teaches it)
let's see. lists are introduced on page 19, a more extensive discussion of
lists is
found on page 33, the del statement appears on page 34, and the dir() function
is
Alan Morgan wrote:
In article [EMAIL PROTECTED],
Raymond Hettinger [EMAIL PROTECTED] wrote:
* s.clear() is more obvious in intent
Serious question: Should it work more like s=[] or more like
s[:]=[]. I'm assuming the latter, but the fact that there is
a difference is an argument for not
Steven D'Aprano wrote:
Convenience and obviousness are important for APIs -- that's why lists
have pop, extend and remove methods. The only difference I can see between
a hypothetical clear and these is that clear can be replaced with a
one-liner, while the others need at least two, e.g. for
Fredrik Lundh wrote:
Peter Hansen wrote:
One of very first things newcomers learn (I believe, though I don't know
how soon the tutorial teaches it)
let's see. lists are introduced on page 19, a more extensive discussion of
lists is
found on page 33, the del statement appears on page 34,
Peter Hansen wrote:
You're spending a lot of time trying to convince me I'm wrong
no, I'm just posting observable facts in response to various I'm too
lazy to look this up, but I'll assume that things are this way posts.
Thankfully (to Georg)
it's fixed in the wiki too...
talking about the
I agree. Lists should have a clear method. But what's shocking is that
it doesn't seem obvious to others. list.clear() is a whole lot more
readable, intuitive, flowable and desirable than del list. Or maybe I
haven't had enough coffee this morning. I'd go as far as saying all
container objects
[Mystilleef]
Lists should have a clear method. But what's shocking is that
it doesn't seem obvious to others. list.clear() is a whole lot more
readable, intuitive, flowable and desirable than [the alternatives]
+1 to all of that.
--
Richie Hindle
[EMAIL PROTECTED]
--
A perspective that I haven't seen raised here is inheritance.
I often say
mylist = []
if I'm done with the current contents and just want a fresh list.
But the cases where I have really needed list.clear [and laboriously
looked for it and ended up with
del l[:]
were when the object was my
Raymond Hettinger wrote:
[Steven Bethard]
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out the best
examples from this thread and turn
Mel Wilson wrote:
for item in seq:
L.append(item)
Both extend and append have one-line slice equivalents,
except that the equivalents have to keep referring to
the length of the list.. (have to keep finding the
len function.)
fwiw, the *tutorial* defines append and extend in terms
* the request is inane, the underlying problem is trivial, and the
relevant idiom is fundamental (api expansions should be saved for rich
new functionality and not become cluttered with infrequently used
redundant entries)
Is this sort of editorialising fair, or just a way of
Raymond Hettinger wrote:
Also, in the python-dev world, making something more OO is neither a
virtue nor a vice.
except that arguments along the line of if the syntax is not obj.method(),
it's not OO enough are likely to be mostly ignored.
(nobody's going to be impressed by yet another
Fredrik Lundh [EMAIL PROTECTED] wrote:
except that arguments along the line of if the syntax is not obj.method(),
it's not OO enough are likely to be mostly ignored.
(nobody's going to be impressed by yet another len(obj) isn't OO variant)
Does that suggest that what's needed is clear(obj) and
[Dan Christensen]
It's true that this runs at the same speed as the del variants on my
machine. That's not too surprising to me, but I still don't
understand why the del variants are more than 5% faster than the first
version.
Understanding it involves looking at implementation specific
Peter Hansen [EMAIL PROTECTED] writes:
[...]
Then it's a good reason we had this thread, so you could learn something
*crucial* to understanding Python and writing non-buggy code: name
binding versus variables which occupy fixed memory locations like in
some other languages. This has to be
Em Sex, 2006-04-14 às 09:17 +0400, Sergei Organov escreveu:
I, as a newcomer, don't have much trouble understanding the binding vs
the assignment by themselves. What does somewhat confuse is dual role of
the = operator, -- sometimes it means bind and other times it means
assign, right? For me
Martin v. Löwis wrote:
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del x[:]'
100 loops, best
Martin v. Löwis wrote:
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del x[:]'
100 loops, best
Felipe Almeida Lessa wrote:
Em Qua, 2006-04-12 às 11:36 +1000, Steven D'Aprano escreveu:
On Tue, 11 Apr 2006 19:15:18 +0200, Martin v. Löwis wrote:
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4
On Wed, 12 Apr 2006 00:33:29 -0700, Serge Orlov wrote:
Felipe Almeida Lessa wrote:
Em Qua, 2006-04-12 às 11:36 +1000, Steven D'Aprano escreveu:
On Tue, 11 Apr 2006 19:15:18 +0200, Martin v. Löwis wrote:
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options,
Steven D'Aprano wrote:
But that is precisely the same for the other timeit tests too.
for _i in _it:
x = range(10)
Allocate list.
Allocate ob_item array to hold pointers to 1 objects
Allocate 99900 integer objects
setup list
del x[:]
Calls list_clear which:
decrements
Steven D'Aprano wrote:
But name.clear() meaning mutate the object referenced by name to the
empty state is a very natural candidate for a method, and I don't
understand why lists shouldn't have it.
Funny this even comes up, because I was just trying to 'clear' a list
the other day. But it
Steven D'Aprano wrote:
On Tue, 11 Apr 2006 14:49:04 -0700, Ville Vainio wrote:
John Salerno wrote:
Thanks guys, your explanations are really helpful. I think what had me
confused at first was my understanding of what L[:] does on either side
of the assignment operator. On the left, it just
Steven Bethard wrote:
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out the best
examples from this thread and turn it into a PEP?
John Salerno wrote:
Steven Bethard wrote:
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out the best
examples from this thread and
Georg Brandl wrote:
John Salerno wrote:
Steven Bethard wrote:
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out the best
examples from
John Salerno wrote:
Steven Bethard wrote:
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out the best
examples from this thread and turn it
John Salerno wrote:
Steven Bethard wrote:
I think these are all good reasons for adding a clear method, but
being that it has been so hotly contended in the past, I don't think
it will get added without a PEP. Anyone out there willing to take out
the best examples from this thread and
Steven D'Aprano wrote:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del x[:]'
100 loops, best of 3: 6.35 msec per loop
$ python2.4 -mtimeit 'x = range(10); x[:] = []'
100 loops, best of 3: 6.36 msec per loop
Ville Vainio wrote:
Fredrik Lundh wrote:
because Python already has a perfectly valid way to clear a list,
perhaps ?
del l[:]
Ok. That's pretty non-obvious but now that I've seen it I'll probably
remember it. I did a stupid while l: l.pop() loop myself.
Actually, it's in the Library
[Steven Bethard]
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out the best
examples from this thread and turn it into a PEP?
Something
Em Qua, 2006-04-12 às 12:40 -0700, Raymond Hettinger escreveu:
* the existing alternatives are a bit perlish
I love this argument =D! perlish... lol...
Cheers,
--
Felipe.
--
http://mail.python.org/mailman/listinfo/python-list
[Felipe Almeida Lessa]
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del x[:]'
100 loops, best of 3: 6.35 msec per loop
$
Raymond Hettinger wrote:
Cons:
-
* learning slices is basic to the language (this lesson shouldn't be
skipped)
And yet it doesn't appear to be in the tutorial. I could have missed
it, but I've looked in a number of the obvious places, without actually
going through it (again) from
Raymond Hettinger wrote:
* easier to figure-out, look-up, and remember than either s[:]=[] or
del s[:]
Easier is an understatement - it's something you figure out
automatically. When I want to do something w/ an object, looking at its
methods (via code completion) is the very first thing.
*
Ville Vainio wrote:
Assigning to slices is much less important, and is something I always
never do (and hence forget).
ALMOST never, of course.
--
http://mail.python.org/mailman/listinfo/python-list
In article [EMAIL PROTECTED],
Raymond Hettinger [EMAIL PROTECTED] wrote:
[Steven Bethard]
I think these are all good reasons for adding a clear method, but being
that it has been so hotly contended in the past, I don't think it will
get added without a PEP. Anyone out there willing to take out
On Wed, 12 Apr 2006 12:40:52 -0700, Raymond Hettinger wrote:
Something this small doesn't need a PEP. I'll just send a note to
Guido asking for a pronouncement.
Raymond, if you're genuinely trying to help get this sorted in the
fairest, simplest way possible, I hope I speak for everyone when
On Wed, 12 Apr 2006 15:36:47 -0700, Alan Morgan wrote:
Serious question: Should it work more like s=[] or more like
s[:]=[]. I'm assuming the latter, but the fact that there is
a difference is an argument for not hiding this operation behind
some syntactic sugar.
Er, I don't see how it can
In article [EMAIL PROTECTED],
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Wed, 12 Apr 2006 15:36:47 -0700, Alan Morgan wrote:
Serious question: Should it work more like s=[] or more like
s[:]=[]. I'm assuming the latter, but the fact that there is
a difference is an argument for not hiding
Alan Morgan wrote:
Right. I was wondering what would happen in this case:
s=[1,2,3]
t=s
s.clear()
t # [] or [1,2,3]??
If you know your basic python it is obvious what would happen
if you do s=[] or s[:]=[] instead of s.clear() and I guess it is
equally obvious which one s.clear()
Steven D'Aprano wrote:
Convenience and obviousness are important for APIs -- that's why lists
have pop, extend and remove methods. The only difference I can see between
a hypothetical clear and these is that clear can be replaced with a
one-liner, while the others need at least two, e.g. for
In article [EMAIL PROTECTED],
Peter Hansen [EMAIL PROTECTED] wrote:
Alan Morgan wrote:
Right. I was wondering what would happen in this case:
s=[1,2,3]
t=s
s.clear()
t # [] or [1,2,3]??
If you know your basic python it is obvious what would happen
if you do s=[] or s[:]=[] instead
Peter Hansen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
It's not even clear that extend needs two lines:
s = range(5)
more = list('abc')
s[:] = s + more
s
[0, 1, 2, 3, 4, 'a', 'b', 'c']
This is not the same as list.extend because it makes a separate
intermediate list
Raymond Hettinger [EMAIL PROTECTED] writes:
Felipe Almeida Lessa writes:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del
I tried to clear a list today (which I do rather rarely, considering
that just doing l = [] works most of the time) and was shocked, SHOCKED
to notice that there is no clear() method. Dicts have it, sets have it,
why do lists have to be second class citizens?
--
Ville Vainio wrote:
I tried to clear a list today (which I do rather rarely, considering
that just doing l = [] works most of the time) and was shocked, SHOCKED
to notice that there is no clear() method. Dicts have it, sets have it,
why do lists have to be second class citizens?
because
Fredrik Lundh wrote:
I tried to clear a list today (which I do rather rarely, considering
that just doing l = [] works most of the time) and was shocked, SHOCKED
to notice that there is no clear() method. Dicts have it, sets have it,
why do lists have to be second class citizens?
Ville Vainio wrote:
I tried to clear a list today (which I do rather rarely, considering
that just doing l = [] works most of the time) and was shocked, SHOCKED
to notice that there is no clear() method. Dicts have it, sets have it,
why do lists have to be second class citizens?
This gets
Em Ter, 2006-04-11 às 10:42 -0600, Steven Bethard escreveu:
one of::
del lst[:]
lst[:] = []
or if you don't need to modify the list in place,
lst = []
Personally, I tend to go Fredrik's route and use the first.
I love benchmarks, so as I was testing the options, I
Steven Bethard wrote:
If you feel really strongly about this though, you might consider
writing up a PEP. It's been contentious enough that there's not much
chance of getting a change without one.
No strong feelings here, and I'm sure greater minds than me have
already hashed this over
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del x[:]'
100 loops, best of 3: 6.35 msec per loop
$
Ville Vainio wrote:
It's just that, when I have an object, and am wondering how I can clear
it, I tend to look what methods it has first and go to google looking
for idioms second.
I guess del on a list is not that common, so people tend to not know
that it works on lists (and slices!), too.
Steven Bethard wrote:
lst[:] = []
lst = []
What's the difference here?
--
http://mail.python.org/mailman/listinfo/python-list
Em Ter, 2006-04-11 às 17:56 +, John Salerno escreveu:
Steven Bethard wrote:
lst[:] = []
lst = []
What's the difference here?
lst[:] = [] makes the specified slice become []. As we specified :, it
transforms the entire list into [].
lst = [] assigns the value [] to the
John Salerno wrote:
Steven Bethard wrote:
lst[:] = []
lst = []
What's the difference here?
L[:]= modifies the object in place, L=[] binds the variable to a
new object. compare and contrast:
L = [a, b, c]
M = L
L
['a', 'b', 'c']
M
['a', 'b', 'c']
L is M
True
L[:] = []
L
John Salerno wrote:
Steven Bethard wrote:
lst[:] = []
lst = []
What's the difference here?
lst = [1,2,3]
lst2 = lst
lst[:] = []
lst2
[]
lst = [1,2,3]
lst2 = lst
lst = []
lst2
[1, 2, 3]
Duncan
--
http://mail.python.org/mailman/listinfo/python-list
Felipe Almeida Lessa wrote:
You see? lst[:] removes all elements from the list that lst refers to,
while lst = [] just creates a new list and discard the only one. The
difference is, for example:
Thanks, your explanation was great!
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
John Salerno wrote:
Steven Bethard wrote:
lst[:] = []
lst = []
What's the difference here?
L[:]= modifies the object in place, L=[] binds the variable to a
new object. compare and contrast:
Thanks guys, your explanations are really helpful. I think what
John Salerno wrote:
Thanks guys, your explanations are really helpful. I think what had me
confused at first was my understanding of what L[:] does on either side
of the assignment operator. On the left, it just chooses those elements
and edits them in place; on the right, it makes a copy of
On Tue, 11 Apr 2006 14:49:04 -0700, Ville Vainio wrote:
John Salerno wrote:
Thanks guys, your explanations are really helpful. I think what had me
confused at first was my understanding of what L[:] does on either side
of the assignment operator. On the left, it just chooses those elements
On Tue, 11 Apr 2006 19:15:18 +0200, Martin v. Löwis wrote:
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x =
Em Qua, 2006-04-12 às 11:36 +1000, Steven D'Aprano escreveu:
On Tue, 11 Apr 2006 19:15:18 +0200, Martin v. Löwis wrote:
Felipe Almeida Lessa wrote:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100
Felipe Almeida Lessa [EMAIL PROTECTED] writes:
I love benchmarks, so as I was testing the options, I saw something very
strange:
$ python2.4 -mtimeit 'x = range(10); '
100 loops, best of 3: 6.7 msec per loop
$ python2.4 -mtimeit 'x = range(10); del x[:]'
100 loops, best of 3: 6.35
78 matches
Mail list logo
