"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
>
>
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 eas
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
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[:] = []
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
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
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
[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 d
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(o
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
> > * 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 no
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
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 an
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 o
[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]
--
http://mail.python
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 sh
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 t
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 pag
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. fo
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 argu
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
i
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 state
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
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 thi
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
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 coul
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 li
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 fin
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.
>
>
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 met
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 = ran
"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 separa
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
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. fo
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 on
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 f
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
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
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 t
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
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.
>
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 s
[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
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
[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?
Somethin
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
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.3
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 thr
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
>>>exa
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 thr
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?
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
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 i
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
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 tes
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:
> > >>
> >
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[:]'
> > 1
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[:]'
> > 10
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
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)
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 =
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 el
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
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 help
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
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/list
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']
>
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 []
Steven Bethard wrote:
> lst[:] = []
> lst = []
What's the difference here?
--
http://mail.python.org/mailman/listinfo/python-list
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!), to
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
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 suf
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 op
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
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?
because P
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?
--
http://mail.python.org/mailman/lis
78 matches
Mail list logo