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 first two are changing the
list in-place, but why is that better? Isn't the end result the same?
Thanks in advance.
--
Steven.
65  4135 
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 are (1) and (2) preferred? I think the first two are changing the
list in-place, but why is that better? Isn't the end result the same?
No. Consider this simple example:
class Foo(object):
def __init__(self, all_my_thingies):
self.all_my_thingies = all_my_thingies
things = [1,2,3,4,5]
f = Foo(things)
things = [] # I've been robbed
print f.all_my_thingies # or not?
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!
Diez
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 are (1) and (2) preferred? I think the first two are changing the
list in-place, but why is that better? Isn't the end result the same?
Thanks in advance.
--
Steven.
The solution (1) and (2) clear the content of the list (replace the
content of the list by an empty list for (1), or delete the content of
the list for (2) while the solution (3) creates a new list and binds the
old name to the new list. This means that you don't actually modify
(clear) the initial list.
Just try it out: a = range(10)
a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] b = a
b
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] c = a
c
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] a.append(10) # assert that a, b and c point to the same list
a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] b
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] c
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] b = []
b
[] a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] del c[:]
c
[] a
[]
Here we can see that using method (3) on b didn't modify the content of
a (even though we asserted that they were the same list).
Using method (2) on c, the other hand, did modify the content of a.
This is because method (3) on b actually created a new list and bound
"b" (as a name) to that new list, without modifying the list "b" used to
be bound to (which is the one "a" and "c" are still bound to).
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 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
collector), and the program can be (quite) faster (this is true in some
implementations different from CPython too).
Bye,
bearophile
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 are (1) and (2) preferred? I think the first two are changing the
list in-place, but why is that better? Isn't the end result the same?
I'm wondering why there is no 'clear' for lists. It feels like a common
operation for mutable containers. :-/
Will McGugan
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:
(3) mylist = []
Why are (1) and (2) preferred? I think the first two are changing the
list in-place, but why is that better? Isn't the end result the same?
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).
l = []
is all you need!
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
On Mon, 06 Feb 2006 13:35:10 +0000, 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).
l = []
is all you need!
Not so. If that logic were correct, then dicts wouldn't need a clear
method either, because you could just assign a new empty dict with d = {}.
But your own sentence tells us why this is not sufficient: because you
aren't emptying the list, you are reassigning (rebinding) the name. The
old list still exists, and there is no guarantee that it will be garbage
collected, because there is no guarantee that it isn't in use somewhere
else:
L = [0,1,2]
D = {"key": L}
L = [] # rebinds the name L, but the list instance still exists
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.
--
Steven.
On Tue, 07 Feb 2006 01:01:43 +1100,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote: On Mon, 06 Feb 2006 13:35:10 +0000, 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).
l = []
is all you need!
Not so. If that logic were correct, then dicts wouldn't need a clear
method either, because you could just assign a new empty dict with d = {}.
But your own sentence tells us why this is not sufficient: because you
aren't emptying the list, you are reassigning (rebinding) the name. The
old list still exists, and there is no guarantee that it will be garbage
collected, because there is no guarantee that it isn't in use somewhere
else:
L = [0,1,2]
D = {"key": L}
L = [] # rebinds the name L, but the list instance still exists
That is a red herring. Consider this:
L = [object(), object()]
O = L[1]
L = [] # or insert your favorite list-clearing/emptying statement here
What damage is done now that O is still referring to one of the items
that used to be in L?
The trouble begins when references to "the list to which L refers" end
up somewhere else. Then we have to wonder if rebinding L will leave
some other block of code with an outdated list.
Regards,
Dan
--
Dan Sommers
<http://www.tombstonezero.net/dan/>
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 case where "patches are welcome"...
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 another case where "patches are welcome"...
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.
(del doesn't work on dictionaries)
</F>
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': 3, 'b': 2} del d['b']
print d
{'a': 1, 'c': 3} del d[:]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unhashable type
Regards. Mel.
On Mon, 06 Feb 2006 09:39:32 -0500, Dan Sommers wrote: On Tue, 07 Feb 2006 01:01:43 +1100,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
On Mon, 06 Feb 2006 13:35:10 +0000, 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).
l = []
is all you need! Not so. If that logic were correct, then dicts wouldn't need a clear
method either, because you could just assign a new empty dict with d = {}.
But your own sentence tells us why this is not sufficient: because you
aren't emptying the list, you are reassigning (rebinding) the name. The
old list still exists, and there is no guarantee that it will be garbage
collected, because there is no guarantee that it isn't in use somewhere
else:
L = [0,1,2]
D = {"key": L}
L = [] # rebinds the name L, but the list instance still exists
That is a red herring. Consider this:
L = [object(), object()]
O = L[1]
L = [] # or insert your favorite list-clearing/emptying statement here
What damage is done now that O is still referring to one of the items
that used to be in L?
What relevance is this? If there is one and only one reference to the list
L, then it will be garbage collected when L is rebound. I never denied
that. I pointed out that, in the general case, you may have multiple
references to the list (not all of which are bound to names), and
rebinding the name L will NOT have the side-effect of clearing the list.
The trouble begins when references to "the list to which L refers" end
up somewhere else. Then we have to wonder if rebinding L will leave
some other block of code with an outdated list.
Precisely, just as my example shows.
--
Steven.
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 sequences.
Possibly another case where "patches are welcome"...
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 all be handled with a while loop (at
various costs of efficiency, clarity or obviousness).
del L[:] works, but unless you are Dutch, it fails the
obviousness test. It also fails the introspection test:
neither dir(list) nor help(list) make it easy to
discover how to empty a list. In my opinion, the
primary advantage for a clear() method would be that it
is self-documenting.
--
Steven.
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 all be handled with a while loop (at
various costs of efficiency, clarity or obviousness).
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.
both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.
It also fails the introspection test:
so does "print L".
</F>
[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 fails the
obviousness test.
[Fredrik Lundh] unless you read some documentation, that is. del on sequences
and mappings is a pretty fundamental part of Python. so are slicings.
both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.
Fred is exactly correct. Slicing is absolutely basic to Python.
Accordingly, it gets covered right at the beginning of the tutorial
(section 3.1). Likewise, the del keyword is fundamental -- if you
can't get, set, and del, then you need to go back to collections
school.
Also specious is the suggestion that dir(L) or help(L) is useless. The
entries for the __delitem__ and __delslice__ methods are no more hidden
than for __getitem__ or __add__. The help entry goes a step further
and shows the translation to del x[y] and del x[i:j].
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.
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.
Raymond Hettinger
[be************@lycos.com] 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
collector), and the program can be (quite) faster (this is true in some
implementations different from CPython too).
There should be almost no difference in runtime between the two. The
underlying CPython implementation caches list objects and is usually
able to create the new list without any calls to the memory allocator.
Likewise, garbage collection performs the same for both -- any objects
left with no references are immediately freed and any with only
circular references get freed when the collector runs.
The speed-up you observed likely occured with different code. For
instance, given a large list, you can typically update or replace
individual elements faster than you can build-up a new list:
L = [0] * 1000 # starting list
for i in xrange(len(L)):
L[i] += 1
beats:
L = [0] * 1000 # starting list
L = [L[i]+1 for i in xrange(len(L))]
Raymond
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[:] works, but unless you are Dutch, it fails the
obviousness test.
[Fredrik Lundh] unless you read some documentation, that is. del on sequences
and mappings is a pretty fundamental part of Python. so are slicings.
both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.
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
mentions of shell scripts. I don't want to criticise the hard work that
went into making the tutorial but let's not pretend it's the epitome of
documentation or even necessary the most obvious reference for users.
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 hardly ever find myself using slices, never mind in a
mutable context.
del L[:] is not obvious, especially given the existence of clear() in
dictionaries. I'm not necessarily requesting a clear() method, but I am
requesting a little more understanding towards those who expected one.
The list interface is full of redundant convenience methods, so one
more would hardly be a surprise or an unreasonable thing for people to
expect. Again we unfortunately have a bit of an attitude problem
towards anyone posting here that doesn't know whatever the experts
think is obvious.
--
Ben Sizer
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 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.
Well, for those who can't find it you just provided a fairly pithy
Raymond Hettinger quote :-)
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
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 coming to Python as a well less than the average programmer,
I agree wholeheartedly with Mr. Peters.
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 resented and
resisted promulgation of the Python is Easy meme.
Pity that this stance has separated me from a sense of belonging to the
community, which seems to so highly value that meme.
Art
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 resented and
resisted promulgation of the Python is Easy meme.
Pity that this stance has separated me from a sense of belonging to the
community, which seems to so highly value that meme.
What Python *is*, to me, is a game worth playing. Not something I come
across all that often. And easy games, almost invariably, are not.
Art
On 7 Feb 2006 00:27:05 -0800, Raymond Hettinger <py****@rcn.com> 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.
The problem is that the average programmer in question isn't
hypothetical in this case.
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
collections school is. I doubtless have read of it at some point, but
as no importance has ever been attached to it, I have probably not
remembered it.
Similarly, I remember slices simply because they are handy, not
because I have ever heard of them being fundamental before.
(I don't argue their fundamentalness one way or other, it's just that
you seem to think that all people who have learned Python have some
knowledge of this hugely important feature).
The other problem with your use of the quote is that the smartness of
the average programmer, or their ability to understand the feature, is
not in question. It is their ability to know of the existence of the
feature, or to find out about it.
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.
Ed
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 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.
Well, for those who can't find it you just provided a fairly pithy
Raymond Hettinger quote :-)
for the record, the original quote is:
The "of course, while *I* have no problem with this at all, it's
surely too much for a lesser being" flavor of argument always rings
hollow to me. Are you personally confused by the meanings for "+" that
exist today? *Objecting* to the variations is a different story; I'm
wondering whether you personally stumble over them in practice. I
don't; Steven doesn't; I doubt that you do either. I'm betting that
almost *nobody* ever does, in which case those "less nimble colleagues
and students" must be supernaturally feeble to merit such concern.
-- Tim Peters, 29 Apr 1998
</F>
On 7 Feb 2006 02:02:42 -0800, Ben Sizer <ky*****@gmail.com> 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
mentions of shell scripts.
Now that is GPotD (Good Point of the Day) which is much better than
QotW as it's actually useful.
I don't want to criticise the hard work that
went into making the tutorial but let's not pretend it's the epitome of
documentation or even necessary the most obvious reference for users.
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 hardly ever find myself using slices, never mind in a
mutable context.
del L[:] is not obvious, especially given the existence of clear() in
dictionaries. I'm not necessarily requesting a clear() method, but I am
requesting a little more understanding towards those who expected one.
The list interface is full of redundant convenience methods, so one
more would hardly be a surprise or an unreasonable thing for people to
expect. 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
be strong (and confusing) resistance to making Python easier and more
obvious. I can only assume that it is by people who have forgotten
what it is like to be an average programmer. (Paul Graham constantly
makes the same mistake when he goes on about how everyone should use
lisp).
Ed
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
collections school is. I doubtless have read of it at some point, but
as no importance has ever been attached to it, I have probably not
remembered it.
I'm probably below average as a programmer, except when compared with
my immediate colleagues [1]. I wrote an extremely simple (albeit
non-conventional) tutorial on learning how to program with Python,
partly as a means to learn Python myself. (Google for rur-ple if you
are curious.) I introduced del shortly after I introduced lists. I
think it is important that one learns at least a couple of example
usage of every Python keyword as soon as possible, before attempting to
write complicated programs. The same probably goes for built-in
functions.
André
[1] Because I have none.
> 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 fundamental ops in almost any
computing context: songs on your iPod playlist, records in a database,
files in a directory, or elements in a Python list.
Individual element deletion doesn't seem to come-up as much in Python
because we tend to build data collections and then throw them away in
their entirity. However, the concept becomes more prominent when
dealing with persistence or when mutating a collection in-place. The
OP was specifically seeking to do in-place modifications and so found
himself in need of understanding the del-statement. IMHO, it goes with
the territory.
Similarly, I remember slices simply because they are handy, not
because I have ever heard of them being fundamental before.
FWIW, I regard slices to be fundamental to the language not because
they are easy or that everyone automatically knows about them; rather,
I am just recognizing that the concept of slices pervades the language
and comes up in many different guises. It is a lesson that should not
be skipped. That is why I think that the OP's problem is better solved
by improved documentation than by adding an unnecessary method to the
list API.
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.
I would swap the first two. No language has yet been invented
(including HTML and LOGO) that someone doesn't struggle with. In
contrast, no documentation has ever been written that couldn't be
improved.
The "problem with the person" part goes last only because it suggests
immutability. The reality is that incomplete learning is a fixable
problem (independent of language or doc issues). If I never learn the
del-statement, should I be surprised that I stuggle with how to express
deletion?
Raymond
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 hardly ever find myself using slices, never mind in a
mutable context.
I just grepped through my codebase, and while I do see a number of dels
with dicts, and a number of dels with instance attributes, I see only
two dels with lists, both from the same module. So I think your point
about infrequent use of del, at least with lists, is pretty valid.
I suspect this is reinforced by the fact that del is usually not the
right way to go when using lists -- repeated dels in the middle of a
list is almost always less efficient than other techniques due to the
underlying array implementation.
That said, I didn't find anywhere in my codebase that I needed to clear
a list (i.e. where ``L = []`` wasn't perfectly fine), while I do find a
small number of dict clears. So I guess I don't really care if clearing
a list is a little less intuitive than clearing a dict.
STeVe
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, clarity or obviousness).
del L[:] works, but unless you are Dutch, it fails the
obviousness test.
[Fredrik Lundh] unless you read some documentation, that is. del on sequences
and mappings is a pretty fundamental part of Python. so are slicings.
both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.
I don't agree with that at all. I'd been programming python for a while (a
year?) before i knew about del l[:].
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.
Ditto.
Why should it magically spring to mind in this occasion? Similarly I
hardly ever find myself using slices, never mind in a mutable context.
del L[:] is not obvious, especially given the existence of clear() in
dictionaries.
Agreed.
tom
--
GOLDIE LOOKIN' CHAIN [...] will ultimately make all other forms of music
both redundant and unnecessary -- ntk
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't Perl, thank Guido.
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. That's a wart, minor but easily fixed.
--
--Bryan
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 mappings, and lists are not. mappings don't
support slicing. lists do.
are you sure you know Python ?
</F>
In article <ma***************************************@python. org>,
Fredrik Lundh <fr*****@pythonware.com> 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* mappings. I believe that a mapping should support
__getitem__(); in addition, sets do not consist of key/value pairs like
any other mapping.
(Just to be clear, I do agree with your basic point; I'm nitpicking on a
tangent.)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/
"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
On 07/02/06, Fredrik Lundh <fr*****@pythonware.com> 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 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.
are you sure you know Python ?
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
On 07/02/06, Raymond Hettinger <py****@rcn.com> 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
be strong (and confusing) resistance to making Python easier and more
obvious.
That is B.S.
We simply disagree on whether list.clear() is an improvement. Adding a
non-essential method to an important API does not make the language
t > easier to learn or use.
Yes it does. It makes it a lot easier to learn. Even list.del()
would be a massive improvement.
Also, it doesn't address the wider issue that
learning about slices is important for understanding the language (it
appears in many guises). Likewise, learning about the del-statement is
somewhat essential for people setting out to mutate collections
in-place. You're not helping someone if you steer them away from
learning the basics.
Maybe it's better to put the basics in a place that they will find
them, rather than trying to steer them. Manipulating the language is
hell of a lot easier than manipulating every user.
Languages are only there for people to use therefore I'm going to go
out on a limb and say that they should be designed for people to use. I can only assume that it is by people who have forgotten
what it is like to be an average programmer.
More B.S.
My thoughts on the issue are informed by several years of answering
average programmer questions on the python-help list. In that time,
the question of how to clear a list has never come up. There are
several areas of recurring confusion but this isn't one of them.
You're mud-slinging over a non-issue.
My thoughts on the issue are informed by many years of being an
average programmer and knowing and working with lots of average
programmers (and well below average programmers for that matter)
I'm not mud-slinging, I'm just saying that people are very dismissive
of making the language easier to use for newbies.
Ed
On 7 Feb 2006 07:08:17 -0800, Raymond Hettinger <py****@rcn.com> 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.
I would swap the first two. No language has yet been invented
(including HTML and LOGO) that someone doesn't struggle with. In
contrast, no documentation has ever been written that couldn't be
improved.
(I should clarify that by documentation, I mean external documentation
rather than self-documentation features)
Given the choice of having a language that is hard to use but has good
documentation or one that is easy to use but has bad documentation,
which would you go for?
If you could write the perfect language, would it be so easy to use
(including self-documentation) that no one ever needed to look things
up in external documentation, or would it have such good documentation
that you could always find what you needed in external documentation?
Documentation is there to cover up the cracks in the none-obvious (or
confusing) parts of the language. Python is starting to show that one
day anything but the most perfunctory documentation may one day become
unnecessary.
Ed
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 that's important.
</F>
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 both have a clear()
method and lists do not.
dicts and sets are mappings, and lists are not.
Sets are mappings? Look up the terms, or check the library doc:
http://docs.python.org/lib/lib.html
mappings don't
support slicing. lists do.
Do they all have an empty state? Can you figure out what a clear()
method for lists should do, just from what it does for sets and
dicts?
are you sure you know Python ?
Why would you post a messages like that?
--
--Bryan
On 07/02/06, Fredrik Lundh <fr*****@pythonware.com> 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" that their experiences don't count, and that you are the
only newbie that's important.
No, I'm saying that people are very dismissive of making things easier
to use for newbies (as you yourself were only a few posts ago)
Ed
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 remember it, and therefore it is not an issue. It is another
issue altogether to say "When I want to CLEAR a list, I think of DELETING
A SLICE, and anyone who doesn't obviously doesn't know Python."
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 read the right book, had
the right teacher, taken the right college degree.
I understand that get/set/del of slices is absolutely fundamental to
lists. I understand that lists are not precisely the same as dicts. I
understand that if you read help(list) and see the entry for the __del__
method and extrapolate sufficiently you will come up with del L[:] as a
technique for clearing a list.
But I also see that Python includes convenience methods, like pop and
extend and insert, and it is my opinion is that Python's clarity would be
slightly increased if lists had a clear() method.
That's a very mild claim, and I don't understand why there is so much
vehemence against the suggestion. It's not like I suggested Python should
get rid of slicing altogether. If it is just "I've had a bad week and I'm
grumpy", then I can understand that -- I've been there and done that. If
it's "I hate the word 'clear' and it fills me with rage that dicts have a
clear method too", then I'll just back away slooowly now.
But if there are good, solid reasons for rejecting *this particular*
(hypothetical) convenience method, then I'd like to hear about them, sans
questions about my ability to program in Python.
Thank you,
--
Steven.
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 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 term "extend slicing". http://www.python.org/doc/2.4.2/ref/slicings.html
"The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list contains
at least one comma, the key is a tuple containing the conversion of the
slice items; otherwise, the conversion of the lone slice item is the
key. The conversion of a slice item that is an expression is that
expression. The conversion of an ellipsis slice item is the built-in
Ellipsis object. The conversion of a proper slice is a slice object
(see section 3.2) whose start, stop and step attributes are the values
of the expressions given as lower bound, upper bound and stride,
respectively, substituting None for missing expressions."
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 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 term "extend slicing". http://www.python.org/doc/2.4.2/ref/slicings.html
"The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list contains
at least one comma, the key is a tuple containing the conversion of the
slice items; otherwise, the conversion of the lone slice item is the
key. The conversion of a slice item that is an expression is that
expression. The conversion of an ellipsis slice item is the built-in
Ellipsis object. The conversion of a proper slice is a slice object
(see section 3.2) whose start, stop and step attributes are the values
of the expressions given as lower bound, upper bound and stride,
respectively, substituting None for missing expressions."
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 read the right book, had
the right teacher, taken the right college degree.
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. why is that so hard to understand ?
</F> bo****@gmail.com 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 slicing. lists do.
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 term "extend slicing".
http://www.python.org/doc/2.4.2/ref/slicings.html
"The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list contains
at least one comma, the key is a tuple containing the conversion of the
slice items; otherwise, the conversion of the lone slice item is the
key. The conversion of a slice item that is an expression is that
expression. The conversion of an ellipsis slice item is the built-in
Ellipsis object. The conversion of a proper slice is a slice object
(see section 3.2) whose start, stop and step attributes are the values
of the expressions given as lower bound, upper bound and stride,
respectively, substituting None for missing expressions."
This is in place to support multidimensional arrays, such as in numpy.
If, for instance, you have a 9x9 array A, then A[3:6,3:6] will extract a
3x3 block from the center of it. A[3:6,3:6] is equivalent to
A[(slice(3,6,None), slice(3,6,None))] and the resulting tuple gets
passed through the mapping interface, but it is not a mapping in any
real sense.
I don't think there's anything in core Python that uses this and it's
not really relevant to this thread.
-tim
Tim Hochberg wrote: bo****@gmail.com 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 slicing. lists do.
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 term "extend slicing".
http://www.python.org/doc/2.4.2/ref/slicings.html
"The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list contains
at least one comma, the key is a tuple containing the conversion of the
slice items; otherwise, the conversion of the lone slice item is the
key. The conversion of a slice item that is an expression is that
expression. The conversion of an ellipsis slice item is the built-in
Ellipsis object. The conversion of a proper slice is a slice object
(see section 3.2) whose start, stop and step attributes are the values
of the expressions given as lower bound, upper bound and stride,
respectively, substituting None for missing expressions."
This is in place to support multidimensional arrays, such as in numpy.
If, for instance, you have a 9x9 array A, then A[3:6,3:6] will extract a
3x3 block from the center of it. A[3:6,3:6] is equivalent to
A[(slice(3,6,None), slice(3,6,None))] and the resulting tuple gets
passed through the mapping interface, but it is not a mapping in any
real sense.
I don't think there's anything in core Python that uses this and it's
not really relevant to this thread.
Thanks. I would say that it is not relevant to the OP's question but
the thread has turned to "anyone who read the doc should know about
slicing" and that prompted me to go and read the doc(I don't have the
OP's mentioned need in my coding so far and never read about the full
pontential of slicing, just use it as the right hand side intuitively)
about slicing and found the documentation to be a bit lacking(only a
brief mentioning of slicing in the turtorial and this confusing
section).
Beside, just from reading this page, it seems that a[start:stop:stride]
is not a valid construction for sequence object 'a'.
To me, reading the doc makes me more confuse about what is slicing.
[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
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
collections school is. I doubtless have read of it at some point, but
as no importance has ever been attached to it, I have probably not
remembered it.
Similarly, I remember slices simply because they are handy, not
because I have ever heard of them being fundamental before.
Ok, I can understand that, but I think that you really understand
that the strength of a programming language such as Python is that
it's like lego bricks. You have some basic pieces, and you can
combine them to into something unique that does what you want.
There are plenty of statements, operators, functions, types, modules
and other things in Python already. I can well imagine that you had
forgotten about del, and that you don't immediately think about slices
when you wonder how to empty a list. It's like when I build lego with
my son. I guess he has around 2000 pieces, and it's not always easy
to spot what you need. It was difficult enough when I was a kid. Now
there are so many different kinds of pieces, shaped to fulfil some
niche usecase.
One thing that I'm sure of is this: Making more kinds of odd-shaped
"pieces", especially prepared to solve the specific problem I'm facing
right now, won't make it easier to understand or use Python in the
long run.
I've used Python for almost 10 years now, and I still learn new
things, and I sometimes come across things that I once new but
had forgotten.
It might work for a while to add a new convenience function as soon
as someone finds that they don't immediately now how to solve a
certain problem. It's my impression that that's pretty much the idea
with PHP. It's not Python though. PHP is only successful in a fairly
narrow (if important) niche, it has failed in getting used outside
its niche, and I assume we'll see a decline in its use one the web
pretty soon, just as it happened with Perl. (Whether RoR, something
Python based or something entirely new will replace it is beyond my
radar screen though.)
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 people can turn a bit defensive when some
people who are more skilled in programming than in diplomacy
basically tells the confused that they are ignorant and should
just learn the language.
On the other hand, I think that Art Siegel said it very well:
"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."
(Actually, that's a much better QOTW! It gives me flashbacks from
a book I once read, http://www.amazon.com/gp/product/0060958324 )
There are just a few statements in Python. Some of them should
really have been functions (print and exec) but anyway, they are
still few enough to learn. There are also a few ways to get inside
composite objects, x.y, x[y], x[y:z]. These things are among the
most fundamental in Python.
If luminaries like Fredrik Lundh and Raymond Hettiger tells you
that things should be done in a certain way, it's really just
silly to argue further. I've programmed Python since 1996, but if
these guys tell me I'm wrong, I won't bother to argue. If I don't
understand their position, I'll try to study the subject further,
and I might ask them to clarify, but I'll assume that they are
right. That assumption has worked so far for me.
There are warts and quirks in Python, everybody will agree to that,
but Python is *not* Perl. A basic motto has always been to avoid
synonyms, to try to provide as few ways to do one thing, rather
than to provide as many ways, as possible. This has proven very
successful in making Python easy to learn and use. The opposite
approach has made Perl into the favourite programimng language
among people who think that "if the program was difficult to write,
it should be difficult to read as well!"
When you can't transfer one approach from one type to another,
there is a reason for that. A few times it might be due to some
obscure practical aspect of the implementation, but most of the
time, it's completely intentional, and finding these aspects of
Python, learning why they are the way they are, and embracing the
language rather than trying to fight it, is actually very rewarding.
Tuples aren't just immutable lists--they have different purposes
beyond that. Ordereded and unordered collections are conceptually
different. Neither call-by-referece nor call-by-value describes
parameter passing in Python well, the clue lies in understanding
how assignments and objects work, and you need to understand the
difference between mutable and immutable objects etc. There are
a number of fundamental concepts that you need to understand to
really use Python well.
Python works very smoothly, and you can do a lot of productive
work with it even if you don't know these things, but in time
you'll trip over them, and as you do, you need to grok these
concepts to get further. Asking for some syntactic change or
some convenience method so that you can get a little further
without understanding the fundamental concept isn't the way to
get beyond these little stumbling blocks.
It's a bit as if you call the design department of your car
manufacturer and tell them how they should redesign the suspension
since it was so bumpy when you drove around with flat tires.
Saying that it's too much to ask that you keep the tires filled
with the right amount of air won't meet much sympathy.
On 2/8/06, Fredrik Lundh <fr*****@pythonware.com> 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. why is that so hard to understand ?
"The only 'intuitive' user interface is the nipple. After that, it's
all learned." - Bruce Ediger
--
Cheers,
Simon B, si***@brunningonline.net, http://www.brunningonline.net/simon/blog/
On 08/02/06, Magnus Lycka <ly***@carmen.se> 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
alone that it is fundamental to Python, and I have no idea what
collections school is. I doubtless have read of it at some point, but
as no importance has ever been attached to it, I have probably not
remembered it.
Similarly, I remember slices simply because they are handy, not
because I have ever heard of them being fundamental before.
Ok, I can understand that, but I think that you really understand
that the strength of a programming language such as Python is that
it's like lego bricks. You have some basic pieces, and you can
combine them to into something unique that does what you want.
There are plenty of statements, operators, functions, types, modules
and other things in Python already. I can well imagine that you had
forgotten about del, and that you don't immediately think about slices
when you wonder how to empty a list. It's like when I build lego with
my son. I guess he has around 2000 pieces, and it's not always easy
to spot what you need. It was difficult enough when I was a kid. Now
there are so many different kinds of pieces, shaped to fulfil some
niche usecase.
One thing that I'm sure of is this: Making more kinds of odd-shaped
"pieces", especially prepared to solve the specific problem I'm facing
right now, won't make it easier to understand or use Python in the
long run.
I agree utterly with this, particularly the general philosophy of
having simple bricks that work in as many different places as
possible.
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.
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".
The problem is you have to be very careful when talking about this,
not to use the C-word, because that's the hobgoblin of little minds,
whereas in almost every other field it is considered an important part
of usability.
I've used Python for almost 10 years now, and I still learn new
things, and I sometimes come across things that I once new but
had forgotten.
It might work for a while to add a new convenience function as soon
as someone finds that they don't immediately now how to solve a
certain problem. It's my impression that that's pretty much the idea
with PHP. It's not Python though. PHP is only successful in a fairly
narrow (if important) niche, it has failed in getting used outside
its niche, and I assume we'll see a decline in its use one the web
pretty soon, just as it happened with Perl. (Whether RoR, something
Python based or something entirely new will replace it is beyond my
radar screen though.)
--
http://mail.python.org/mailman/listinfo/python-list
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 = "sky"
s.clear()
</F>
On 08/02/06, Magnus Lycka <ly***@carmen.se> 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?
QOTW! (You are joking, aren't you? :)
It was a genuine question. Judging from one of your other responses,
that you are still learning new things and remembering forgotten ones
after 10 years, I assume the answer is "no, it is not necessary".
(I'm also assuming you find Python easy to use).
The thing that first attracted me to Python was that I only had to
read a page or two of the tutorial before I could get started on doing
little things with Python and find it easy.
I can undestand how people can turn a bit defensive when some
people who are more skilled in programming than in diplomacy
basically tells the confused that they are ignorant and should
just learn the language.
On the other hand, I think that Art Siegel said it very well:
"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."
(Actually, that's a much better QOTW! It gives me flashbacks from
a book I once read, http://www.amazon.com/gp/product/0060958324 )
There are just a few statements in Python. Some of them should
really have been functions (print and exec) but anyway, they are
still few enough to learn. There are also a few ways to get inside
composite objects, x.y, x[y], x[y:z]. These things are among the
most fundamental in Python.
If luminaries like Fredrik Lundh and Raymond Hettiger tells you
that things should be done in a certain way, it's really just
silly to argue further. I've programmed Python since 1996, but if
these guys tell me I'm wrong, I won't bother to argue. If I don't
understand their position, I'll try to study the subject further,
and I might ask them to clarify, but I'll assume that they are
right. That assumption has worked so far for me.
I didn't know they were luminaries. I apologise. I've never heard of
any of the people on the list before I came to Python and the only
people I've learned to trust are Kent Johnson and Alan Gauld. I guess
if I start to see those guys say things that turn out to be right I
might start assuming they are right as well.
Maybe there should be a list of luminaries on the website so we know
who not to argue with?
There are warts and quirks in Python, everybody will agree to that,
but Python is *not* Perl. A basic motto has always been to avoid
synonyms, to try to provide as few ways to do one thing, rather
than to provide as many ways, as possible. This has proven very
successful in making Python easy to learn and use. The opposite
approach has made Perl into the favourite programimng language
among people who think that "if the program was difficult to write,
it should be difficult to read as well!"
I think people concentrate on the total number of ways to do
something, when the obviousness or consistency of one one of those
ways is more important.
For example one of the few things Microsoft does okay at, is in having
a pretty consistent interface across their applications. There's a
menu bar that (theoretically) has all the commands you can perform in
a structured format. But you can also use reasonably consistent
keyboard shortcuts to do something, or context menus for things that
you do a lot.
Having several different ways means that everyone can use the way they
prefer. Beginners tend to use the menu bar a lot as they can always
find what they want there, but can start using the keyboard shortcuts
as they start to perform the action a lot and start to become more
experienced.
I know this isn't entirely applicable but hopefully you see the analogy.
When you can't transfer one approach from one type to another,
there is a reason for that. A few times it might be due to some
obscure practical aspect of the implementation, but most of the
time, it's completely intentional, and finding these aspects of
Python, learning why they are the way they are, and embracing the
language rather than trying to fight it, is actually very rewarding.
No, it's rewarding for a certain type of person. It's not a rewarding
activity for every type of person. I find it deeply frustrating when
I have to constantly look things up to see what is the way of doing
things for this type. I'd rather spend my time writing code then
looking things up to see which way I have to do it now.
Tuples aren't just immutable lists--they have different purposes
beyond that. Ordereded and unordered collections are conceptually
different. Neither call-by-referece nor call-by-value describes
parameter passing in Python well, the clue lies in understanding
how assignments and objects work, and you need to understand the
difference between mutable and immutable objects etc. There are
a number of fundamental concepts that you need to understand to
really use Python well.
Python works very smoothly, and you can do a lot of productive
work with it even if you don't know these things, but in time
you'll trip over them, and as you do, you need to grok these
concepts to get further. Asking for some syntactic change or
some convenience method so that you can get a little further
without understanding the fundamental concept isn't the way to
get beyond these little stumbling blocks.
It's a bit as if you call the design department of your car
manufacturer and tell them how they should redesign the suspension
since it was so bumpy when you drove around with flat tires.
Saying that it's too much to ask that you keep the tires filled
with the right amount of air won't meet much sympathy.
It probably wouldn't meet with much sympathy, but that's not to say
it's not a decent point for someone to make.
Inflatable tyres are getting quite antiquated now. There's plenty of
substances that would be better to fill tyres with than air. there
are already tyres that don't burst when you push a 6-inch nail into
them because they are filled with a hard foam. They work better,
don't puncture, last longer, but hey is it too much to ask for you to
keep your tyres filled with air and replace them every time you get a
puncture and carry a fifth wheel around in case you get a puncture and
there's no way to fix the tyre?
Ed
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 Daniels sc***********@acm.org This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: JustSomeGuy |
last post by:
When you iterate through a list of objects in a list.
list<object> mylist;
list<object>::const_iterator iter;
object ob;
for (iter=mylist.begin(); iter != mylist.end(); ++iter)
{
ob =...
|
by: lallous |
last post by:
Hello
Given this:
list<mystruct_t> lst;
lst.push_back(item1);
lst.push_back(item2);
lst.push_back(item3);
|
by: Brian |
last post by:
Hi
I'm working on a site that has a form on it to do an advanced search on
a database, in the form are 2 list (<select>)
Both these list have items in them, what I want to do is if an items it...
|
by: Wong CS |
last post by:
Dear all,
i hav a problem when i compile my web application... this is the SQL query i
used to insert my data into database.
string InsertBuyerDetail = @"INSERT INTO Buyer (Buy_Login,...
|
by: situ |
last post by:
Hi,
we i get a snapshot for lock on db i'm getting
LOCK_LIST_IN_USE =5560
and
my LOCKLIST parameter = 50,
is it ok for OLTP database or do i have to do any tuning here.
thanks
sridhar
| | |
by: eric dexter |
last post by:
I apologise if I annoy in advance. This is very close to what I want but I need to return a list of instr_numbers not just one and it seems that no matter what I do I just get two items from a split...
|
by: Antony Clements |
last post by:
i have written a program that incorporates the following code.
Private Sub Dir1_Change()
'changes the folder and displays each file in the folder
On Error Resume Next
File1.Path = Dir1.Path...
|
by: Thomas Ploch |
last post by:
Hello fellow pythonists,
I have a question concerning posting code on this list.
I want to post source code of a module, which is a homework for
university (yes yes, I know, please read...
|
by: thungmail |
last post by:
/* The program read several messages from and store them in a singly linked list
*/
typedef struct message {
int messageId;
char * messageText;
struct message * next;...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
