Lists and Tuples

Try this with a list:

a = [1, 2, 3, 4, 5]
a[3] = 27
print a

Then try it with a tuple.

That's true, but another answer is: you should use tuples for short
sequences of diverse items (like the arguments to a function). You
should use lists for longer sequences of similar items.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

Everything? ;)

>>> a = [1, 2, 3, 4]
>>> a.append(5)
>>> a

>>> del a[2]
>>> a
[1, 2, 4, 5]

>>> b = (1, 2, 3, 4)

>>> b.append(5)
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: 'tuple' object has no attribute 'append'

>>> del b[2]
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: object doesn't support item deletion

I think you've missed how important the difference between "mutable" and
"immutable" can be...

Robert Brewer
MIS
Amor Ministries
fuma...@amor.org

What's the difference?

>>> import sets
>>> sets.Set(dir(list)).difference(sets.Set(dir(tuple)))
Set(['sort', 'index', '__delslice__', 'reverse', 'extend', 'insert',
'__setslice__', 'count', 'remove', '__setitem__', '__iadd__', 'pop',
'__delitem__', 'append', '__imul__'])

;)

-Andrew.

association = {}
somevals = 1,2,6,'a'
association[somevals] = 13

vs.

association = {}
somevals = [1,2,6,'a']
association[somevals] = 13

-Scott David Daniels
Scott....@Acm.Org

>>> timeit.Timer("a = (1, 2, 3)").timeit()
0.36679466245011483

>>> timeit.Timer("a = [1, 2, 3]").timeit()
0.82959342598011432

Building the 3-element list takes over twice as long as the 3-element
tuple. Extraction is also faster with tuples:

>>> timeit.Timer("""a = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
... b = a[1]""").timeit()
0.75013975239869524

>>> timeit.Timer("""a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
... b = a[1]""").timeit()
1.2107122553285308

Oh, and in case you're wondering, timeit() runs each statement 1,000,000
times unless you specify otherwise.

> -----Original Message-----
> From: Jeff Wagner [mailto:JWa...@hotmail.com]
> Sent: Thursday, December 04, 2003 9:55 PM
> To: pytho...@python.org
> Subject: Re: Lists and Tuples
>
>
> On 04 Dec 2003 21:31:12 -0800, Paul Rubin
> <http://phr...@NOSPAM.invalid> wrotf:

> That's because a tuple is immutable and a list is mutable but
> what else? I guess I said everything I
> tried with a tuple worked with a list ... not mentioning I
> didn't try to break the immutable/mutable
> rule I was aware of. Besides trying to change a tuple, I
> could cut it, slice and dice it just like I
> could a list. They seemed to have the same built-in methods, too.
>
> >From what I can see, there is no reason for me to ever want
> to use a tuple and I think there is
> something I am missing. Why would Guido go to all the effort
> to include tuples if (as it appears)
> lists are just as good but more powerful ... you can change
> the contents of a list.
>
> Jeff
> --
> http://mail.python.org/mailman/listinfo/python-list
>

I disagree. You should use a tuple when you wish to not change the
contents once you have constructed the sequence, and otherwise you
should use a list. Using a tuple can make your code clearer by
letting the reader know from the beginning that the contents won't be
changing.

Fredrik Lundh actually called me names a couple years back for
asserting this, but Python luminary (and rude fellow) or not, he is
dead wrong.

You don't have to take my word for it, though, since Python itself
uses tuples in this manner, in the form of the container used for
excess arguments (excess arguments certainly don't have to be short,
and they are generally homogeneous, not heterogeneous), and Python
Mega Widgets (for example) is littered with code that looks like:

optiondefs = (
('initwait', 500, None), # milliseconds
('label_background', 'lightyellow', None),
('label_foreground', 'black', None),
('label_justify', 'left', None),
('master', 'parent', None),
('relmouse', 'none', self._relmouse),
('state', 'both', self._state),
('statuscommand', None, None),
('xoffset', 20, None), # pixels
('yoffset', 1, None), # pixels
('hull_highlightthickness', 1, None),
('hull_highlightbackground', 'black', None),
)

In the above case we see tuples being used both as records *and* as an
arbitrary-length sequence of homogenious elements. Why is a tuple
being used in the latter case, rather than a list? Because the
sequence isn't going to be modified.

|>oug

I'm curious what you're getting at. I.e., what does diversity or
similarity have to do with the choice? Is that an aesthetic thing?
(In which case 'should' should be qualified a bit, IWT ;-)
Or what am I missing?

Regards,
Bengt Richter

Nothing really, except by idiom. When people use "should" here, I
think they are over-generalizing. Most of the time, records (short
and heterogenious) are used in a read-only fashion, and long
homogenous sequences are used in a read-write fashion. But when
people characterize this tendency with a "should", I think they are
making a thinko. There are times when you need to modify a record and
consequently might use a dictionary or list, rather than a tuple,
and there are also times when you will never want to modify a long,
homogenous sequence, in which case many people would find it more
elegant to use a tuple than to use a list.

The reason for the "should" is probably because, I imagine, Guido had
in mind mostly multiple return values from function, and the like,
when he put tuples into the language.

|>oug

According to the Python FAQ:

------------------------------------------------------------------------
4.15 Why are there separate tuple and list data types?

Lists and tuples, while similar in many respects, are generally used in
fundamentally different ways. Tuples can be thought of as being similar
to Pascal records or C structs; they're small collections of related
data which may be of different types which are operated on as a group.
For example, a Cartesian coordinate is appropriately represented as a
tuple of two or three numbers.

Lists, on the other hand, are more like arrays in other languages. They
tend to hold a varying number of objects all of which have the same type
and which are operated on one-by-one. For example, os.listdir('.')
returns a list of strings representing the files in the current
directory. Functions which operate on this output would generally not
break if you added another file or two to the directory.

Tuples are immutable, meaning that once a tuple has been created, you
can't replace any of its elements with a new value. Lists are mutable,
meaning that you can always change a list's elements. Only immutable
elements can be used as dictionary keys, and hence only tuples and not
lists can be used as keys.

http://www.python.org/doc/faq/general.html#why-are-there-separate-tuple-and-list-data-types
------------------------------------------------------------------------

Of course, this information will prevent neither flame wars, nor you
from using them how you wish (within the boundaries of the language).
However you choose to use them, just be clear and consistent.

Peace,
Joe

The most practical difference (if you don't need to modify the contents) is
that tuples can be used as dictionary keys, but lists cannot. There is a
minor performance difference, in particular tuples will take less memory so
if you have a few million of them kicking around your application you might
notice the difference.

However, as other posters have suggested the best way to look at it is
often to use tuples when you have a fixed number of objects, possibly of
different types, e.g. a database record. When you have a variable number of
objects (usually of the same type, or supporting a similar interface) then
a list if obviously better. If you have a variable number of groups of
objects, then a list of tuples seems to fit best. In any of these cases you
could use a list in place of the tuple, but the distinction can help keep
things clear.

Bottom line:

If you are primarily reading the sequence using constant indices, then use
a tuple. If the code starts looking messy then consider defining a class to
replace the tuples and using fieldnames instead of constant indices.

If you need to use the object as a dictionary key, or if you have reason to
be concerned about memory use (because there are a lot of them) use a
tuple.

Otherwise use a list.

--
Duncan Booth dun...@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?

> Fredrik Lundh actually called me names a couple years back for

I'm never dead wrong.

Guido van Rossum, "State of the Python Union", March 2003:
http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt

...

+ It's a matter of user education

+ Example: lists vs. tuples

this is often misrepresented as "tuple are readonly lists",
which is *wrong*

use cases are quite different

*but*... tuples also usable as readonly lists

...

I expect an apology.

</F>

> Jeff Wagner fed this fish to the penguins on Thursday 04 December 2003
> 21:19 pm:

> A tuple can be the key for a dictionary, a list can't.
>
>
> Not sure of a tuple containing a list, though...

Nope. A tuple is hashable iff all of its elements are.

Cheers,
mwh

--
Now this is what I don't get. Nobody said absolutely anything
bad about anything. Yet it is always possible to just pull
random flames out of ones ass.
-- http://www.advogato.org/person/vicious/diary.html?start=60

I like that--ask a simple question, get a simple answer. Why can't
they all be so straightforward. :-)
--dang

> Jeff

The big difference is that tuples (because they are immutable) can be
used as dictionary keys.

So, if you are going to use it as a key, it's got to be a tuple. If
you're going to want to add/delete/change items in it, it's got to be a
list.

If you will never change it, but have no syntatic constraint forcing it
to be immutable, you can pick whichever turns you on. From a stylistic
point of view, I tend to think of tuples when I need to bundle up a
collection of related items (such as a function returning multiple
items). Lists make me think of number of the same kind of item.

I would agree if you're explicitly talking about 2-space or 3-space.
But if you're dealing with higher-order geometries, then a coordinate
becomes an N-vector and now it starts to feel more like a list than a
tuple.

I can't put any rigorous argument behind that, it's just what (to me)
feels right.

The new isinstance() function can take a tuple (but not a list) as its
second argument. Why? Logically, it should take any sequence. The
operation it's doing is essentially:

for aType in sequence:
if isinstance (thing, aType):
return True
return False

I don't see any reason it should reject a list, but it does:

>>> isinstance (1, [str, int])

File "<stdin>", line 1, in ?
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types

This is documented, but it still seems strange. Why go out of your way
to reject a list when a list is really a perfectly reasonable thing to
pass in that context?

Same deal with issubclass().

To me, it's a distinction without a difference. Tuples
*act* like immutable sequences, and I use them that way. I
don't know, though, that I won't get caught some day.

Python 3.3 (#22, Jul 29 2013, 14:34:42) [MSC v.9200 96 bit (Intel)] on win96
Type "help", "copyright", "credits" or "license" for more information.
>>> t = (1,4,7,34,789)

HomogeneityError: tuple elements are not diverse
>>>

Regards. Mel.

What should it do if the second argument is a type object that is also
iterable?

E.g. suppose that iter(bool) produced the sequence True, False. ...

Generally, choose between tuples and lists based upon your data. In
situations where you have a small, fixed collection of objects of possibly
differing types, use a tuple. In situations where have a collection of
objects of uniform type which might grow or shrink, use a list. For
example, an address might best be represented as a tuple:

itcs = ("2020 Ridge Avenue", "Evanston", "IL", "60201")
caffe_lena = ("47 Phila Street", "Saratoga Springs", "NY", "12866")

Though all elements are actually strings, they are conceptually different
types. It probably makes no sense to define itcs as

itcs = ("2020 Ridge Avenue", "60201", "IL", "Evanston")

If you are reading test scores from a file, you'd likely accumulate them
into a list:

scores = []
for line in file("foo"):
scores.append(float(line.strip()))

then operate on them as a group, possibly normalized to the list's length:

nscores = len(scores)
mean = sum(scores)/nscores
variance = sum([(n-mean)**2 for n in scores])/nscores
print "Mean:", mean
print "Variance:", variance

Unlike tuples, it's often perfectly reasonable to reorder lists without any
loss of meaning:

scores.sort()
print "Min:", scores[0]
print "Max:", scores[-1]
print "Median:", scores[nscores/2:nscores/2+1]

Think of lists as arrays and tuples as Pascal records or C structs and
you'll probably choose correctly most of the time.

If you want to associate methods with your tuples (similarly for lists), you
should probably define a class instead:

import latlong

class Address:
def __init__(self, street, city, state, zip):
self.street = street
self.city = city
self.state = state
self.zip = zip

def distance(self, other):
return latlong.cdistance("%s, %s" % (self.city, self.state),
"%s, %s" % (other.city, other.state))

itcs = Address("2020 Ridge Avenue", "Evanston", "IL", "60201")
caffe_lena = Address("47 Phila Street", "Saratoga Springs", "NY", "12866")
print itcs.distance(caffe_lena), "miles"

For the curious, when run, the above prints:

961.976657911 miles

Looks like I won't be attending a concert at Caffe Lena tonight.

(latlong is a module I wrote for use in the Mojam and Musi-Cal websites but
never released publically.)

Skip

That's a good example, because it makes for a nice segue. If you were
holding data from a form that looked like:

Street: ___________________________
City: ___________________________
State: ___________________________
Zip: ___________________________

Then I agree you're looking at a 4-tuple (assuming you didn't want to go
whole-hog and define an Address class). But, imagine a somewhat more
generic form that looked like:

Address line 1: ________________________
Address line 2: ________________________
Address line 3: ________________________
Address line 4: ________________________

You might fill in exactly the same data, but now if feels like it should
be a list.

> Douglas Alan wrote:

You were dead wrong to insult me in a debate over subtle programming
aesthetics, where my opinion is just as well-founded as anyone's.

(0) I would never say that a tuple is a read-only list because a tuple
*isn't* a list. I would say that a tuple is an "immutable
sequence", which is true by definition. The use-cases for mutable
sequences and for immutable sequences are obviously quite
different because in one case you are likely going to mutate the
sequence and in the other case, you clearly are not.

(1) Just because Guido asserts it doesn't make it true.

(2) Guido's own brother Just disagrees with him, proving that it isn't
obvious even if you are Dutch.

(3) Guido apparently disagreed with himself when he made the container
for excess arguments be a tuple.

(4) I have quite a few books on Python, and none of them assert that
tuples should only be used as records, and I have seen numerous
examples of decent code that use tuples as full-fledged immutable
sequences to good purpose. I posted such an example from Pmw in
my previous message.

(5) I have never seen a *single* good reason presented anywhere for
restricting oneself to using tuples only as records. I have only
seen it stated as bold assertion without support.

> I expect an apology.

Ha! The noive of some people!

|>oug

You'll be fine. The only thing you have to watch out for is that some
rude folks here might call you names.

|>oug

def get_values():
#... do stuff ...
return (x,y,z)

(x,y,z) = get_values()

PS, you can turn a tuple into a list quickly with list compressions;

list = [ x for x in tuple ]

--
Michael T. Babcock
C.T.O., FibreSpeed Ltd.
http://www.fibrespeed.net/~mbabcock

What's wrong with the even simplier:

aList = list (aTuple)

I think what he may be getting at is that in the case of a list, you
should be able to perform the same operation(s) on all members. I'm not
sure this is a should or not, but its true in my behaviours as a
programmer at least.

def runquery(query):
try:
# do stuff
except query_error, e:
errors += e
result_count = len(results)
return (result_count, results, errors)

(count, results, errors) = runquery( ... )

... but then results would probably be a list of rows ...

results = [
{ 'id': 1, 'name': 'Michael', 'position': 'Hacker' },
{ 'id': 2, 'name': 'Dave', 'position': 'Boss' }
]

Each item in the list does not have to be the same, but I usually assume
that a list of 'somethings' is homogenous. In this case, all items are
result-sets from the database. I expect nothing from a tuple ;-).

Does this make sense?

Roy> What's wrong with the even simplier:

Roy> aList = list (aTuple)

It doesn't use the language feature du jour. ;-)

Skip

Roy> Street: ___________________________
Roy> City: ___________________________
Roy> State: ___________________________
Roy> Zip: ___________________________

Roy> Then I agree you're looking at a 4-tuple (assuming you didn't want
Roy> to go whole-hog and define an Address class). But, imagine a
Roy> somewhat more generic form that looked like:

Roy> Address line 1: ________________________
Roy> Address line 2: ________________________
Roy> Address line 3: ________________________
Roy> Address line 4: ________________________

Roy> You might fill in exactly the same data, but now if feels like it
Roy> should be a list.

I think you're thinking too hard. ;-) What about:

Street 1: ___________________________
Street 2: ___________________________
Street 3: ___________________________

? I might use a tuple containing a list. Of course, in some situations,
the "natural form" your data takes has other external influences. If I was
storing addresses in a SQL table I might use a tuple of five strings (one
per column in the database) and just suffer with the fact that I couldn't
have more than three street elements. If addresses were stored in a pickle
file, I'd might go with a tuple containing a list and three strings.

have-we-completely-snowed-the-OP-yet?-ly, y'rs,

Skip

I should know better than to have anything to say here. But I did
once start a thread on this subject, having been confused a) by the
questions being addressed here and b) specifically by a definitive
statement Guido had made on the subject.

And was surprised - I admit pleasantly - that some folks with
recognizable names in the commumity, and close to Guido, commented
that Guido's take on this subject were his own. And there were other
views, as well.

And then there was discussion that certainly helped me understand what
it was that Guido meant. And the discussion was helpful, to me.

But am surprised to see a point trumped here, simply by quoting Guido.

Art

"Simply" being the operative word, or perhaps "trumped"... I think
you're missing context, which was an apparent(*) claim that point of view
A was _universally correct_ while B was "dead wrong". By referring
the Guido's comment, I believe Fredrik was "simply" indicating that
he couldn't have been "dead wrong" by any usual definition of that
term, as at least one other person (perhaps only coincidentally
the BDFL) shared the same view.

-Peter

(*) As was clarified later, the "dead wrong" comment was actually
intended to be a sort of rudeness objection, and not at all a
contradiction of the B point of view, as it appeared to be.

>What's the difference?
>

Items in lists and not in tuples:

And Items in tuples and not in lists:

>>> sets.Set(dir(tuple)).difference(sets.Set(dir(list)))
Set(['__getnewargs__'])

Items in both tuples and lists:

>>> sets.Set(dir(tuple)).intersection(sets.Set(dir(list)))
Set(['__getslice__', '__str__', '__getattribute__', '__rmul__',
'__lt__', '__init__', '__setattr__', '__reduce_ex__', '__new__',
'__contains__', '__class__', '__doc__', '__len__', '__mul__',
'__ne__', '__getitem__', '__reduce__', '__iter__', '__add__',
'__gt__', '__eq__', '__delattr__', '__le__', '__repr__', '__hash__',
'__ge__'])

Maybe someone could tell me how and/or when __getnewargs__ is used?

_Ronald Adam

Jeff Wagner wrote:

> On 04 Dec 2003 21:31:12 -0800, Paul Rubin <http://phr...@NOSPAM.invalid> wrotf:

> That's because a tuple is immutable and a list is mutable but what else? I guess I said everything I
> tried with a tuple worked with a list ... not mentioning I didn't try to break the immutable/mutable
> rule I was aware of. Besides trying to change a tuple, I could cut it, slice and dice it just like I
> could a list. They seemed to have the same built-in methods, too.

Should you wish to use a sequence as the key for a dictionary, then a
tuple would be the choice.

Colin W.
>
> Jeff

PEP 307 ("Extensions to the pickle protocol") might be somewhat
helpful:

http://www.python.org/peps/pep-0307.html

</F>

list comprehensions have been around for ages. to show off,
you'll need to get itertools and generators into the mix.

</F>

I actually had to dig up the thread that has caused you such grief
over the years.

as expected, you spent that thread attacking everyone who dis-
agreed with you, misrepresented other people's arguments, referred
to implementation artifacts and design mistakes as "proof", and used
the same muddled thinking as you've shown in this thread. heck,
Tim even introduced the term "douglas-sequences" in contrast to
"python-sequences" in order to make any sense of what you were
arguing about that time. not the kind of behaviour I'd expect from
anyone who wants to be taken seriously.

two years later, you haven't learned a thing; that's pretty tragic.

</F>

Some of my confusion derived from these semantic issues. We are
strongly typed and when the list/tuple distinction starts to be talked
with the words "types"," homogenous" , "heterogenous" in close
proximity - we, on the receiving end, will ....

I think the potential misdriection is obvious from your explanation
above.

"Type" is not normally an ambiguous word. It seems to me that an
explanation would stress, upfront, that in fact
homogenous.hetereogenous in this context is at an abstract level, and
unrelated to type,as such and as your example illustrates.

Or else, why does the word "type" need to occur at all, other than
perhaps to explain, explicitily, it is not of relevance

Rather than in a way that implies that it is.

This is a question really. Though not properly phrased as one. Because
I fear I am still missing something.

Art

really? in my experience, "type" and "object" are about as ambiguous
as words can get, especially when you're talking about Python.

</F>

I am sure you are right. On faith. Though its not particularly
helpful.

Art

Or else I can rephrase my question.

Having learned that type and object are highly ambiguous words, why do
we would tend to use them when wanting to clarify list/tuple
distinctions.

Art

Your characterization of the past debate is not only a self-serving
caricature, but it is disingenuous as well. I never attacked or
misrepresented anyone -- I merely disagreed with them. Only you
attacked anyone, Fredrik. As you chose to do again. And
misrepresent.

And you still resort to insults, rather than reason. Yes, tragic,
especially for someone who is apparently an icon of the Python
community.

And speaking of "proof" for one's point -- you never provided a single
iota of evidence, much less proof, for the idea that tuples should
only be used as records, except for that you and Guido say so.

|>oug

Hrm. I see your point, but I also think it's fairly easy to get people
to agree on definitions for "type" and "object" within the context of a
discussion. From my POV, the ambiguity comes from layering on additional
meanings beyond that supported by the C API.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.

what C API? (duck)

So you're saying he's a news commentator for Fox News? ;>)

Now if somebody can just figure out why:

threading.Thread(args=())

but:

threading.Timer(args=[])

we'll have this topic nailed down pretty well. ;)

FuManChu

different authors; the threading module itself is really old (1.5?),
but the Timer class was added in 2.2, and nobody spotted the
inconsistency at that time.

not sure if this can/should be fixed; there might be someone out
there doing:

t = threading.Timer(interval, function)
t.args.append(value)
t.start()

</F>

FuManChu

> --
> http://mail.python.org/mailman/listinfo/python-list
>

| "Type" is not normally an ambiguous word. It seems to me that an

Apologies in advance if someone has already said this. It may
be a little too algebraic for the Python world, but for me the
difference can be expressed like this -

n > 0 or m < sizeof(a) and
conceptual_type(a) == conceptual_type(a[n:m])

If that holds, then the conceptual type is naturally implemented
with a list.

I'm not sure it's right to say that the elements of a tuple are
necessarily of conceptually different types, distinguished only
by their positiion. But the point is that they _are_ distinguished
by position (so a slice is not substitable with its source.)

Of course this still relies on a notion of conceptual type that
can't be expressed literally in Python, but it's a healthy one.

Donn Cave, do...@drizzle.com

That would add some spice to Python's error messages...

Python 3.7 (#1, Sep 31 2007, 14:19:37)
[GCC 5.6.7] on slartibartfast
Type "help", "copyright", "credits" or "license" for more information.
>>> t = (1, 3, 77, 654, 8)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
HumiliationError: The programmer is a pink-faced baboon (tuple used where
list would be more appropriate)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

...

And chicks on blocks but not on clocks...

In MVP (Microsoft Visual Python), the "auto-correct" function would just
silently change the ()'s to []'s as you typed them. If you tried to
change them back, clippy would pop up on the screen and say, "You seem
to be trying to do something un-pythonic. Would you like some
assistance?". If you tried to make clippy go away, it would offer to
"install this critical security patch immediately".

> Douglas Alan wrote:

Hmmm, could I catch the exception and then continue on anyway? Kind
of like casting away const in C++?

|>oug

Hmmm..Sep 31? Should I file a bug report? ;o)

John

Give some credit.

The unitype system will have been inplemented by then.

One's decoded DNA sequence will be accessed (some people thought web
services would be a bust, back in aught 3), with reference to which,
one's intentions are determined.

Programming now called "hinting". CH4E.

Art

I actually see the point also, with direct relevance to Lists and
Tuple tutorial semantics, to the extent that I am confused whether
instances of different classes are of the same "type".

I have considered no. By inheriting from object and creating something
new from it I am creating a custom type. I thought. I think this
impression comes from my little experinece with other languages. And
since the way I use lists are to group instances of different classes,
which may have nothing in common other than a single method of the
same name, I have considered my lists to be of heterogenous type.
Which is why I have been confused by the language to describe the
prototypical use of lists.

Art

Greg> ...

Greg> And chicks on blocks but not on clocks...

Through three cheese trees, three free fleas flew...

Skip

No you didn't <wink>. But, in the Holiday Spirit, I'm terribly sorry, and
while I don't expect you to forgive me, I promise I'll do my best to see
that it never happens again.

if-only-an-apologetic-spirit-were-contagious-ly y'rs - tim

You're failing to take into account the (highly controversial)
International Calendar Reform of 2006, which gave all months
the same number of days. Python was, of course, the first
language to have its datetime module updated to conform with
the new standard.

(Microsoft Java++#.NET was updated too, but in a subtly
incompatible way -- all their months were given 30
days instead.)

it's well known (at least to insiders) that the bug in MSJPCS.NET was the
reason for the reform.

a "32 days is better for computers" alternative was brought forward by the
usual suspects (IBM, Sun, etc, plus a bunch of bloggers hellbent on teaching
Dave Winer a lesson), but was, as usual, largely ignored by everyone else.

31 might be due to a EU translation error, but I'm not sure. I also hear that
the french edition of the standard uses 13 days.

</F>

I accept your apology. Tim, you are a scholar and a gentleman.

|>oug

That would be totally broken, mutable default args and all. In the
Thread class, the mutable kwargs argument isn't so bad, since it's
assigned to a "private" attribute, but the _Timer class uses a plain
attr, so is asking for trouble.

Even if I know my code doesn't modify mutable arguments yet need a
default, I'd still code it like this:

def foo(kwargs=None):
if kwargs is None:
kwargs = {}
...

Maybe I'm too strict here, but I think using mutable default arguments
is at _least_ bad style.

Just