Magnus Lycka wrote:
> Bryan Olson wrote:
>
>> Magnus Lycka wrote:
>>
>>> Bryan Olson wrote:
>>>
big_union = set()
for collection in some_iter:
big_union.update(t)
collection.clear()
>>>
>>>
>>> I don't understand the second one. Where did 't' come from?
Bryan Olson wrote:
> Magnus Lycka wrote:
>
>> Bryan Olson wrote:
>>> big_union = set()
>>> for collection in some_iter:
>>> big_union.update(t)
>>> collection.clear()
>>
>> I don't understand the second one. Where did 't' come from?
>
> Cut-and-past carelessness. Meant to
Raymond Hettinger wrote:
[...]
> If you're asking why list's don't have a clear() method, the answer is
> that they already had two ways to do it (slice assignment and slice
> deletion) and Guido must have valued API compactness over collection
> polymorphism.
That's a decision from long ago. Now
> > If you're asking why list's don't have a clear() method, the answer is
> > that they already had two ways to do it (slice assignment and slice
> > deletion) and Guido must have valued API compactness over collection
> > polymorphism. The latter is also evidenced by set.add() vs
> > list.append
Magnus Lycka wrote:
> Bryan Olson wrote:
>
>> Magnus Lycka wrote:
>>
>>> Do you really have a usecase for this? It seems to me that your
>>> argument is pretty hollow.
>>
>>
>> Sure:
>>
>> if item_triggering_end in collection:
>> handle_end(whatever)
>> collection.clear()
>>
>>
Magnus Lycka wrote:
> >>> class BryansList(list):
> ... add=list.append
> ... def clear(self):
> ... del self[:]
> ...
> >>> b = BryansList([1,2,3,4,5])
> >>> b
> [1, 2, 3, 4, 5]
> >>> b.add(6)
> >>> b.clear()
> >>> b
> []
>
> Happy now? You can keep it, I don't need it. :)
>
Bryan Olson wrote:
> Magnus Lycka wrote:
>> Do you really have a usecase for this? It seems to me that your
>> argument is pretty hollow.
>
> Sure:
>
> if item_triggering_end in collection:
> handle_end(whatever)
> collection.clear()
>
> Or maybe moving everything from severa
Raymond Hettinger wrote:
> [Alex]
> > So what is the rationale for having list SO much harder to use in such a
> > way, than either set or collections.deque?
>
> Sounds like a loaded question ;-)
>
> If you're asking why list's don't have a clear() method, the answer is
> that they already had two
[Alex Martelli]
> I was thinking of something different again, from a use case I did have:
>
> def buncher(sourceit, sentinel, container, adder, clearer):
> for item in sourceit:
> if item == sentinel:
> yield container
> clearer()
> else
> ad
Bryan Olson <[EMAIL PROTECTED]> wrote:
...
> > I agree that emptying is logically the same thing for all of these
> > types. Beyond that, they don't seem to have a lot in common. It's
...
> > Do you really have a usecase for this? It seems to me that your
> > argument is pretty hollow.
>
> S
Magnus Lycka wrote:
> Bryan Olson wrote:
>
>> The original question was about idioms and understanding, but
>> there's more to the case for list.clear. Python is "duck typed".
>> Consistency is the key to polymorphism: type X will work as an
>> actual parameter if and only if X has the required me
Bryan Olson wrote:
> The original question was about idioms and understanding, but
> there's more to the case for list.clear. Python is "duck typed".
> Consistency is the key to polymorphism: type X will work as an
> actual parameter if and only if X has the required methods and
> they do the expec
Magnus Lycka wrote:
> Ed Singleton wrote:
>
>> The point is that having to use del to clear a list appears to the
>> inexperienced as being an odd shaped brick when they've already used
>> the .clear() brick in other places.
>
>
> Agreed. The smart way to go from this stage of surprise is
> not
"Magnus Lycka" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Statements and operators are really fundamental in Python. We
> don't support n = 1.add(2), since we have the '+' operator.
Actually, since the 2.2 union of type and new-style classes, which gave
attributes to all type
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I am confused. Could you explain this ? I was under the impression said
> above(mapping don't support slicing), until after I read the language
> reference. I don't think it is slicing as in the list slicing sense but
> it does use the
A slim lady in a brown overcoat appears and says with a silly
French accent: "Lizten very carefully, I vill zay ziz only onze."
BTW, I happen to reply to Ed's post now, but I'm really responding
to a fairly common attitude which I find somewhat counterproductive.
I hope people are openminded and a
Magnus Lycka wrote:
>... I sometimes come across things that I once new but had forgotten.
I'm sorry, and I mean no offense, _but_ I think _new_ there is a
lovely typo. :-) I stopped, corrected it in my head, proceeded,
and then I backed up, put it back and laughed out loud.
--Scott David Daniel
On 08/02/06, Magnus Lycka <[EMAIL PROTECTED]> wrote:
> Ed Singleton wrote:
> > Is it obvious to a newbie what the difference between mappings and
> > "not-mappings", and is it obvious exactly what is and isn't a mapping?
> >
> > Should it be necessary to "know" python before it becomes easy to use?
Ed Singleton wrote:
> Having bricks that work in lots of places makes the language
> 'guessable'. "I've never cleared a list before, but I've cleared
> dictionaries and I guess the same way would work here".
f = open("foo")
f.clear()
sys.stdout.clear()
os.getcwd().clear()
shelve.clear()
s =
On 08/02/06, Magnus Lycka <[EMAIL PROTECTED]> wrote:
> Ed Singleton wrote:
> > I'm a fairly average programmer (better than average compared to my
> > immediate colleagues). I've read every tutorial I can get my hands
> > on, but I have no _memory_ of ever coming across the del keyword, let
> > a
On 2/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> you seem to be missing that we're talking about a programming language
> here. nothing is obvious if you don't know anything about the language;
> a lot of things are obvious once you've learned a little about it. a little
> is
> all it takes
Ed Singleton wrote:
> Is it obvious to a newbie what the difference between mappings and
> "not-mappings", and is it obvious exactly what is and isn't a mapping?
>
> Should it be necessary to "know" python before it becomes easy to use?
QOTW! (You are joking, aren't you? :)
I can undestand how p
Ed Singleton wrote:
> I'm a fairly average programmer (better than average compared to my
> immediate colleagues). I've read every tutorial I can get my hands
> on, but I have no _memory_ of ever coming across the del keyword, let
> alone that it is fundamental to Python, and I have no idea what
[Ed Singleton]
> Is it obvious to a newbie what the difference between mappings and
> "not-mappings", and is it obvious exactly what is and isn't a mapping?
FWIW, there is a glossary in the tutorial:
http://docs.python.org/tut/node18.html
--
http://mail.python.org/mailman/listinfo/python-lis
Tim Hochberg wrote:
> [EMAIL PROTECTED] wrote:
> > Fredrik Lundh wrote:
> >
> >>>Python now has, what, three built-in mutable collections types:
> >>>lists, dictionaries, and sets. Dicts and sets both have a clear()
> >>>method and lists do not.
> >>
> >>dicts and sets are mappings, and lists are
[EMAIL PROTECTED] wrote:
> Fredrik Lundh wrote:
>
>>>Python now has, what, three built-in mutable collections types:
>>>lists, dictionaries, and sets. Dicts and sets both have a clear()
>>>method and lists do not.
>>
>>dicts and sets are mappings, and lists are not. mappings don't
>>support slici
Steven D'Aprano wrote:
> As for the earlier suggestion that it would be obvious if only I'd done
> the tutorial, if you need to be taught something it is hardly obvious
> is it? Otherwise "obvious" loses all meaning, and we can say any feature,
> no matter how obscure, is obvious if only you'd rea
Fredrik Lundh wrote:
> > Python now has, what, three built-in mutable collections types:
> > lists, dictionaries, and sets. Dicts and sets both have a clear()
> > method and lists do not.
>
> dicts and sets are mappings, and lists are not. mappings don't
> support slicing. lists do.
I am confus
Fredrik Lundh wrote:
> > Python now has, what, three built-in mutable collections types:
> > lists, dictionaries, and sets. Dicts and sets both have a clear()
> > method and lists do not.
>
> dicts and sets are mappings, and lists are not. mappings don't
> support slicing. lists do.
I am confus
On Tue, 07 Feb 2006 22:32:40 +0100, Fredrik Lundh wrote:
> are you sure you know Python ?
Oh my, a little tetchy today aren't we?
Obviousness is a subjective matter! It is one thing to say that 9 out of
10 programmers not only discover this technique (by reading the tutorial
perhaps) but remembe
On 07/02/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Ed Singleton wrote
>
> > I'm not mud-slinging, I'm just saying that people are very dismissive
> > of making the language easier to use for newbies.
>
> no, you're telling people who have long experience in explaining things
> to "newbies" tha
Fredrik Lundh wrote:
> Bryan Olson wrote:
>
>
>>So is consistency; it ain't Perl, thank Guido.
>
> consistency is the hobgoblin of little minds.
Look up that saying. Any clues?
>>Python now has, what, three built-in mutable collections types:
>>lists, dictionaries, and sets. Dicts and sets bo
Ed Singleton wrote
> I'm not mud-slinging, I'm just saying that people are very dismissive
> of making the language easier to use for newbies.
no, you're telling people who have long experience in explaining things
to "newbies" that their experiences don't count, and that you are the
only newbie
On 7 Feb 2006 07:08:17 -0800, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > As a general rule of thumb, I would say that if a person is struggling
> > with a language, it is primarily a problem with the language, and than
> > problem with the documentation, and lastly a problem with the person.
On 07/02/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Again we unfortunately have a bit of an attitude problem
> > > towards anyone posting here that doesn't know whatever the experts
> > > think is obvious.
> >
> > I agree wholeheartedly with this, particularly as there often seems to
> >
On 07/02/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Bryan Olson wrote:
>
> > So is consistency; it ain't Perl, thank Guido.
>
> consistency is the hobgoblin of little minds.
>
> > Python now has, what, three built-in mutable collections types:
> > lists, dictionaries, and sets. Dicts and sets b
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>dicts and sets are mappings, and lists are not. mappings don't
>support slicing. lists do.
>
>are you sure you know Python ?
Actually, after spending some time thinking about this, I've decided
that sets are *not* mappin
Bryan Olson wrote:
> So is consistency; it ain't Perl, thank Guido.
consistency is the hobgoblin of little minds.
> Python now has, what, three built-in mutable collections types:
> lists, dictionaries, and sets. Dicts and sets both have a clear()
> method and lists do not.
dicts and sets are m
Fredrik Lundh wrote:
> Steven D'Aprano wrote:
[...]
>>del L[:] works, but unless you are Dutch, it fails the
>>obviousness test.
>
>
> unless you read some documentation, that is. del on sequences
> and mappings is a pretty fundamental part of Python. so are slicings.
So is consistency; it ain
On Tue, 7 Feb 2006, Ben Sizer wrote:
> Raymond Hettinger wrote:
>> [Steven D'Aprano]
The Zen isn't "only one way to do it". If it were, we
wouldn't need iterators, list comps or for loops,
because they can all be handled with a while loop (at
various costs of efficiency, clarit
Ben Sizer wrote:
>> Likewise, the del keyword is fundamental -- if you
>> can't get, set, and del, then you need to go back to collections
>> school.
>
> I have hardly used the del keyword in several years of coding in
> Python. Why should it magically spring to mind in this occasion?
> Similarly
> I'm a fairly average programmer (better than average compared to my
> immediate colleagues). I've read every tutorial I can get my hands
> on, but I have no _memory_ of ever coming across the del keyword, let
> alone that it is fundamental to Python,
My thought is that get/set/del are fundamen
Arthur wrote:
>
> My ability to grok Python to any extent, from that starting point, was
> based on an understanding that it was my responsibility to come to
> Python, not it to me. And concerted, almost obsessive effort, And time.
>
> OTOH - because of exactly these factors - I have actively r
Ed Singleton wrote:
>
> I'm a fairly average programmer (better than average compared to my
> immediate colleagues). I've read every tutorial I can get my hands
> on, but I have no _memory_ of ever coming across the del keyword, let
> alone that it is fundamental to Python, and I have no idea wha
On 7 Feb 2006 02:02:42 -0800, Ben Sizer <[EMAIL PROTECTED]> wrote:
> > Fred is exactly correct. Slicing is absolutely basic to Python.
> > Accordingly, it gets covered right at the beginning of the tutorial
> > (section 3.1).
>
> Yes, right after UTF encoding details, complex numbers, and various
Steve Holden wrote:
>> While the sentiment behind the list.clear() suggestion is noble, it is
>> an exercise in futility to design a language around the presumption
>> that other programmers are incapable of learning the basics of the
>> language.
>
> +1 QOTW
>> There was a pithy Tim Peters quota
On 7 Feb 2006 00:27:05 -0800, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> There was a pithy Tim Peters quotation to the effect that he was
> unpersuaded by language proposals predicated on some hypothetical
> average programmer not being smart enough to understand something that
> the rest of u
Raymond Hettinger wrote:
>
> There was a pithy Tim Peters quotation to the effect that he was
> unpersuaded by language proposals predicated on some hypothetical
> average programmer not being smart enough to understand something that
> the rest of us find to be basic.
Peters pithy ;)
As someone
Raymond Hettinger wrote:
> [Steven D'Aprano]
[...]
>
> While the sentiment behind the list.clear() suggestion is noble, it is
> an exercise in futility to design a language around the presumption
> that other programmers are incapable of learning the basics of the
> language.
>
+1 QOTW
> There w
Raymond Hettinger wrote:
> [Steven D'Aprano]
> > > The Zen isn't "only one way to do it". If it were, we
> > > wouldn't need iterators, list comps or for loops,
> > > because they can all be handled with a while loop (at
> > > various costs of efficiency, clarity or obviousness).
> > >
> > > del L[
[EMAIL PROTECTED]
> In my programs I have seen that there is another practical difference
> between version 1 and 3:
> (1) mylist[:] = []
> (3) mylist = []
> If you create a big mylist again and again many times, the version 1
> uses the memory more efficiently (probably less work for the garbage
>
[Steven D'Aprano]
> > The Zen isn't "only one way to do it". If it were, we
> > wouldn't need iterators, list comps or for loops,
> > because they can all be handled with a while loop (at
> > various costs of efficiency, clarity or obviousness).
> >
> > del L[:] works, but unless you are Dutch, it
Steven D'Aprano wrote:
> > so we can have three ways to do the same thing? the right way to
> > nuke a sequence is to do "del L[:]". this is explained in Python 101.
>
> The Zen isn't "only one way to do it". If it were, we
> wouldn't need iterators, list comps or for loops,
> because they can a
Fredrik Lundh wrote:
> Peter Hansen wrote:
>
>
>>>Perhaps it is arguable that there is no need for a clear method because
>>>L[:] = [] is so easy to do. Personally, while I agree that it is easy, it
>>>is hardly intuitive or obvious, and I too would prefer an explicit clear
>>>method for mutable
On Mon, 06 Feb 2006 09:39:32 -0500, Dan Sommers wrote:
> On Tue, 07 Feb 2006 01:01:43 +1100,
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 06 Feb 2006 13:35:10 +, Steve Holden wrote:
I'm wondering why there is no 'clear' for lists. It feels like a common
operation for mu
Fredrik Lundh wrote:
> (del doesn't work on dictionaries)
... or rather [:] doesn't work on dictionaries ...
Python 2.4.2 (#1, Jan 23 2006, 21:24:54)
[GCC 3.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d={'a':1, 'b':2, 'c':3}
>>> print d
{'a': 1, 'c
Peter Hansen wrote:
> > Perhaps it is arguable that there is no need for a clear method because
> > L[:] = [] is so easy to do. Personally, while I agree that it is easy, it
> > is hardly intuitive or obvious, and I too would prefer an explicit clear
> > method for mutable sequences.
>
> Possibly
Steven D'Aprano wrote:
> Perhaps it is arguable that there is no need for a clear method because
> L[:] = [] is so easy to do. Personally, while I agree that it is easy, it
> is hardly intuitive or obvious, and I too would prefer an explicit clear
> method for mutable sequences.
Possibly another c
On Tue, 07 Feb 2006 01:01:43 +1100,
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Feb 2006 13:35:10 +, Steve Holden wrote:
>>> I'm wondering why there is no 'clear' for lists. It feels like a common
>>> operation for mutable containers. :-/
>>>
>> Because it's just as easy to create
On Mon, 06 Feb 2006 13:35:10 +, Steve Holden wrote:
>> I'm wondering why there is no 'clear' for lists. It feels like a common
>> operation for mutable containers. :-/
>>
> Because it's just as easy to create and assign a new empty list (and
> have the old unused one garbage collected).
>
>
Will McGugan wrote:
> Steven Watanabe wrote:
>
>>I know that the standard idioms for clearing a list are:
>>
>> (1) mylist[:] = []
>> (2) del mylist[:]
>>
>>I guess I'm not in the "slicing frame of mind", as someone put it, but
>>can someone explain what the difference is between these and:
>>
>
Steven Watanabe wrote:
> I know that the standard idioms for clearing a list are:
>
> (1) mylist[:] = []
> (2) del mylist[:]
>
> I guess I'm not in the "slicing frame of mind", as someone put it, but
> can someone explain what the difference is between these and:
>
> (3) mylist = []
>
> Why a
Diez B. Roggisch:
> The reason is that l = [] just rebinds a new object (a list, but it could be
> anything) to a name, while l[:] = [] will alter the object _referred_ to by
> l. That is a HUGE difference!
In my programs I have seen that there is another practical difference
between version 1 and
Steven Watanabe wrote:
> I know that the standard idioms for clearing a list are:
>
> (1) mylist[:] = []
> (2) del mylist[:]
>
> I guess I'm not in the "slicing frame of mind", as someone put it, but
> can someone explain what the difference is between these and:
>
> (3) mylist = []
>
>
Steven Watanabe wrote:
> I know that the standard idioms for clearing a list are:
>
> (1) mylist[:] = []
> (2) del mylist[:]
>
> I guess I'm not in the "slicing frame of mind", as someone put it, but
> can someone explain what the difference is between these and:
>
> (3) mylist = []
>
>
> I know that the standard idioms for clearing a list are:
>
> (1) mylist[:] = []
> (2) del mylist[:]
>
> I guess I'm not in the "slicing frame of mind", as someone put it, but
> can someone explain what the difference is between these and:
>
> (3) mylist = []
>
> Why are (1) and (2) pre
I know that the standard idioms for clearing a list are:
(1) mylist[:] = []
(2) del mylist[:]
I guess I'm not in the "slicing frame of mind", as someone put it, but
can someone explain what the difference is between these and:
(3) mylist = []
Why are (1) and (2) preferred? I think the fi
67 matches
Mail list logo
