Re: except clause syntax question
Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. On reflection, it seems to hint at a style that Python extensions were made in. (IIRC) the first operand in an `except` statement was originally just an arbitrary marker to identify the exception. Unique string values were customary, although the Python library defined things with standard exception names. Using a string means that general exceptions weren't to be collected in general sequences; `except Serious Error` was never meant to catch `raise r`. If only tuples were used for collections, it would create havoc for fewer of any weirdos who had used strange markers of their own devising. It looks like tuples were chosen as the most lightweight, or maybe least intrusive, sequence type to require to denote a collection of exceptions. You see a similar decision, with the opposite emphasis, with the string modulo operator. The second operand is supposed to be a tuple, but if the template string needs only one value, then the rules are relaxed and any single non-tuple value is used as-is. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Jan 30, 2012, at 7:00 PM, Steven D'Aprano wrote: On Mon, 30 Jan 2012 12:41:00 -0500, Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: Simplicity. If you also allow lists, then why not allow arbitrary sequences? What about iterators, do you allow them? That could be awkward, because iterators can only be run through once. Dictionaries are also iterable, so once you allow arbitrary iterables, you get dicts. The whole thing becomes a mess. Better to keep it simple and only allow a single canonical collection type, and in Python, that type is tuple, not list. Tuples are that canonical collection type because they have a number of desirable properties: - Tuples are small and memory efficient, using the smallest amount of memory needed to hold their items. Lists typically carry a block of spare memory, to make insertions fast. - Consequently the Python virtual machine can create them rapidly and efficiently. - Tuples are immutable, so you don't have to worry about passing one to a function and having the function modify it behind your back. - Tuples are ordered, for the times where that matters. - Since the typical use-case is to iterate over the items in fixed order, there's no need to pay the extra expense for a dict or set. - Tuples are simple to write: in general you only need commas between items. Sometimes, to avoid ambiguity or change the precedence of calculation, you also need round brackets (parentheses for Americans). Except clauses are one of those times. - Frozensets and sets are ruled out for historical reasons: they didn't exist until Python 2.3. Besides, which would you rather write? (abc, def) frozenset([abc, def]) - Sets and lists are ruled out because they are mutable, both require much more memory, and sets have a heavier computational burden. The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. Then you are labouring under a misunderstanding. You're not catching a tuple, because tuples are never thrown. You're catching any of the exceptions that are contained in that tuple. Both lists and tuples *are* single things in themselves. Both lists and tuples are containers: A list is a single thing that contains other things. A tuple is a single thing that contains other things. I don't think of a tuple as a container, and I don't think it a misunderstanding on my part to think this. But I am aware that it is common to use tuples as immutable lists. I don't see that performance was really a consideration, given that one can use any expression in an except statement -- except IOError if today == 'Monday' else OSError as e or L = [] try: #code except tuple(L) as e: pass except Exception, e: L.append(e.__class__) In any case, though I appreciate your attempt at a post hoc justification, I was hoping for a positive explanation. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Tue, 31 Jan 2012 08:57:31 -0500, Charles Yeomans wrote: I don't think of a tuple as a container, and I don't think it a misunderstanding on my part to think this. Well, it is a misunderstanding, because tuples ARE containers. You might as well say I don't think of boxes as containers. What exactly are they if not containers? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Jan 31, 2012, at 9:51 AM, Steven D'Aprano wrote: On Tue, 31 Jan 2012 08:57:31 -0500, Charles Yeomans wrote: I don't think of a tuple as a container, and I don't think it a misunderstanding on my part to think this. Well, it is a misunderstanding, because tuples ARE containers. You might as well say I don't think of boxes as containers. What exactly are they if not containers? Tuple is a heterogenous datatype that allows one to define objects ad hoc. That is to say, a tuple represents a single thing distinct from its components. For example, suppose you need to represent a location in text by line number and offset within a line. A tuple object makes it easy to do so without writing a class having no methods other than a constructor. Here, the components, a line number and an offset, define a new object distinct from the pieces. One can certainly view a tuple as a list, just as one can view a string as a list of characters, and sometimes that's useful; the Python dictum there should only be one way to do it doesn't imply that there is only one way to think of it. Nor am I the only person who sees such a distinction between tuple and list. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Tue, Jan 31, 2012 at 11:23 AM, Charles Yeomans char...@declaresub.com wrote: On Jan 31, 2012, at 9:51 AM, Steven D'Aprano wrote: On Tue, 31 Jan 2012 08:57:31 -0500, Charles Yeomans wrote: I don't think of a tuple as a container, and I don't think it a misunderstanding on my part to think this. Well, it is a misunderstanding, because tuples ARE containers. You might as well say I don't think of boxes as containers. What exactly are they if not containers? Tuple is a heterogenous datatype that allows one to define objects ad hoc. That is to say, a tuple represents a single thing distinct from its components. For example, suppose you need to represent a location in text by line number and offset within a line. A tuple object makes it easy to do so without writing a class having no methods other than a constructor. Here, the components, a line number and an offset, define a new object distinct from the pieces. One can certainly view a tuple as a list, just as one can view a string as a list of characters, and sometimes that's useful; the Python dictum there should only be one way to do it doesn't imply that there is only one way to think of it. Nor am I the only person who sees such a distinction between tuple and list. Perhaps it'd be useful to look at how the Python language reference defines containers? Quote: Some objects contain references to other objects; these are called containers. Examples of containers are tuples, lists and dictionaries. The references are part of a container’s value. In most cases, when we talk about the value of a container, we imply the values, not the identities of the contained objects; however, when we talk about the mutability of a container, only the identities of the immediately contained objects are implied. So, if an immutable container (like a tuple) contains a reference to a mutable object, its value changes if that mutable object is changed. End quote. (Offtopic: How do I do an external block quote appropriately in an email?) Tuples are most certainly containers, precisely _because_ they're an ad-hoc way to define objects, where the only purpose of the object is to contain the values inside the tuple. But these are just words and it's beside the point. We should talk of things as if the word container didn't matter, because I don't think that's what you meant, but neither do I want to put words in your mouth. My interpretation is that you see tuples as an object where you can get meaningfully things by field, rather than just grab arbitrarily from a bag of things. This isn't the only way they are used, see the except statement (hee) and their use as keys in dictionaries. But it is true that their immutable length makes them very well suited to the task of representing product types. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Jan 31, 2012, at 11:38 AM, Devin Jeanpierre wrote: On Tue, Jan 31, 2012 at 11:23 AM, Charles Yeomans char...@declaresub.com wrote: On Jan 31, 2012, at 9:51 AM, Steven D'Aprano wrote: On Tue, 31 Jan 2012 08:57:31 -0500, Charles Yeomans wrote: I don't think of a tuple as a container, and I don't think it a misunderstanding on my part to think this. Well, it is a misunderstanding, because tuples ARE containers. You might as well say I don't think of boxes as containers. What exactly are they if not containers? Tuple is a heterogenous datatype that allows one to define objects ad hoc. That is to say, a tuple represents a single thing distinct from its components. For example, suppose you need to represent a location in text by line number and offset within a line. A tuple object makes it easy to do so without writing a class having no methods other than a constructor. Here, the components, a line number and an offset, define a new object distinct from the pieces. One can certainly view a tuple as a list, just as one can view a string as a list of characters, and sometimes that's useful; the Python dictum there should only be one way to do it doesn't imply that there is only one way to think of it. Nor am I the only person who sees such a distinction between tuple and list. Perhaps it'd be useful to look at how the Python language reference defines containers? Quote: Some objects contain references to other objects; these are called containers. Examples of containers are tuples, lists and dictionaries. The references are part of a container’s value. In most cases, when we talk about the value of a container, we imply the values, not the identities of the contained objects; however, when we talk about the mutability of a container, only the identities of the immediately contained objects are implied. So, if an immutable container (like a tuple) contains a reference to a mutable object, its value changes if that mutable object is changed. End quote. (Offtopic: How do I do an external block quote appropriately in an email?) Tuples are most certainly containers, precisely _because_ they're an ad-hoc way to define objects, where the only purpose of the object is to contain the values inside the tuple. But these are just words and it's beside the point. We should talk of things as if the word container didn't matter, because I don't think that's what you meant, but neither do I want to put words in your mouth. My interpretation is that you see tuples as an object where you can get meaningfully things by field, rather than just grab arbitrarily from a bag of things. This isn't the only way they are used, see the except statement (hee) and their use as keys in dictionaries. But it is true that their immutable length makes them very well suited to the task of representing product types. I had read that bit of documentation, and don't entirely agree with it. Certainly many objects contain references to other objects, but are not considered containers. And I claim that tuples are most certainly not containers, when they are used to define an object as a collection of other objects, like the text-location example I offered earlier. On the other hand, it is certainly true that tuples quack like containers, as do strings. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
Charles Yeomans wrote:
On Jan 31, 2012, at 9:51 AM, Steven D'Aprano wrote:
On Tue, 31 Jan 2012 08:57:31 -0500, Charles Yeomans wrote:
I don't think of a tuple as a container, and I don't think it a
misunderstanding on my part to think this.
Well, it is a misunderstanding, because tuples ARE containers. You
might as well say I don't think of boxes as containers. What
exactly are they if not containers?
Tuple is a heterogenous datatype that allows one to define objects
ad hoc.
And any object can be seen as a container for its component pieces --
some are just more general than others.
Compare:
location = (13, 4, 9)# line, word, char
time = (10, 15, 41) # hour, minute, second
result = ('this', 'that', 'huh') # result a, result b, result c
with:
record1 = Record('Ethan', 41, Male)
record2 = Record('Charles', 37, Male)
record3 = Record('Steven', 43, Male)
record4 = Record('Jennifer', 39, Female)
In this example, Records have a set layout and so it is more common to
think of a Record as a thing; location, time, and result, however, are
all random tuples created on the fly with no absolute restrictions on
what goes in which position.
lists, dicts, sets, and tuples are general purpose containers; strs (and
most user defined classes) are special purpose containers.
That is to say, a tuple represents a single thing distinct from its
components.
You could say that about a list as well. Doesn't change the fact that a
list is a container.
One can certainly view a tuple as a list, just as one can view a string
as a list of characters, and sometimes that's useful; the Python dictum
there should only be one way to do it doesn't imply that there is only
one way to think of it.
The 'dictum' is there should only be one *obvious* way to do it
(emphasis added).
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Jan 31, 2012, at 8:24 AM, Mel Wilson wrote: Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. On reflection, it seems to hint at a style that Python extensions were made in. (IIRC) the first operand in an `except` statement was originally just an arbitrary marker to identify the exception. Unique string values were customary, although the Python library defined things with standard exception names. Using a string means that general exceptions weren't to be collected in general sequences; `except Serious Error` was never meant to catch `raise r`. If only tuples were used for collections, it would create havoc for fewer of any weirdos who had used strange markers of their own devising. It looks like tuples were chosen as the most lightweight, or maybe least intrusive, sequence type to require to denote a collection of exceptions. You see a similar decision, with the opposite emphasis, with the string modulo operator. The second operand is supposed to be a tuple, but if the template string needs only one value, then the rules are relaxed and any single non-tuple value is used as-is. Compatilbility; that makes sense. I came to python well after strings were used for exceptions. Thanks. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
Charles Yeomans char...@declaresub.com wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. It may not be the only reason but the code would have to be slower and much more complex to handle lists. If you wanted you can write: except ((A,), ((B,), C)) as e: or other such complicated expression with nested tuples. If lists were allowed in a similarly nested structure there would be a danger that you could pass in a recursive list structure so the code would have to detect and avoid infinite loops. exceptions = [A, B, C] exceptions[1:1] = exceptions, ... except exceptions as e: # argh! Abitrarily nested tuples of exceptions cannot contain loops so the code simply needs to walk through the tuples until it finds a match. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On 1/31/2012 8:57 AM, Charles Yeomans wrote: In any case, though I appreciate your attempt at a post hoc justification, I was hoping for a positive explanation. I think the best you are going to get is that Python somewhat consistently*, for both practical and historical reasons#, uses tuples when the syntax allows an object or collection of objects. * except, isinstance, isubclass, ''%x, perhaps other places. In the last case, that creates a problem when one wants to interpolate a tuple as an object rather than having it viewed as a container of several objects to be interpolated. That was on # Python once treated tuples as different from lists in ways that is not true now. (Read the 1.5 docs if really interested.) -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Jan 31, 2012, at 7:12 PM, Terry Reedy wrote: On 1/31/2012 8:57 AM, Charles Yeomans wrote: In any case, though I appreciate your attempt at a post hoc justification, I was hoping for a positive explanation. I think the best you are going to get is that Python somewhat consistently*, for both practical and historical reasons#, uses tuples when the syntax allows an object or collection of objects. * except, isinstance, isubclass, ''%x, perhaps other places. In the last case, that creates a problem when one wants to interpolate a tuple as an object rather than having it viewed as a container of several objects to be interpolated. That was on # Python once treated tuples as different from lists in ways that is not true now. (Read the 1.5 docs if really interested.) I'll do that. Thanks. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Wed, Feb 1, 2012 at 9:03 AM, Duncan Booth duncan.booth@invalid.invalid wrote: Abitrarily nested tuples of exceptions cannot contain loops so the code simply needs to walk through the tuples until it finds a match. Is this absolutely guaranteed? The C API for CPython provides: (Py2) http://docs.python.org/c-api/tuple.html#PyTuple_SetItem (Py3) http://docs.python.org/dev/c-api/tuple.html#PyTuple_SetItem which doesn't have massive warnings on it saying USE THIS ONLY TO INITIALIZE A TUPLE (compare, for instance, _PyTuple_Resize which does carry a similar warning). Is the assumption then that we're all adults, and that mutating a tuple is like passing a null pointer to an API function (aka loaded gun in proximity to foot)? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Tue, Jan 31, 2012 at 5:53 PM, Chris Angelico ros...@gmail.com wrote: On Wed, Feb 1, 2012 at 9:03 AM, Duncan Booth duncan.booth@invalid.invalid wrote: Abitrarily nested tuples of exceptions cannot contain loops so the code simply needs to walk through the tuples until it finds a match. Is this absolutely guaranteed? The C API for CPython provides: (Py2) http://docs.python.org/c-api/tuple.html#PyTuple_SetItem (Py3) http://docs.python.org/dev/c-api/tuple.html#PyTuple_SetItem which doesn't have massive warnings on it saying USE THIS ONLY TO INITIALIZE A TUPLE (compare, for instance, _PyTuple_Resize which does carry a similar warning). Is the assumption then that we're all adults, and that mutating a tuple is like passing a null pointer to an API function (aka loaded gun in proximity to foot)? I don't know why the docs are written the way that they are, but if you check the code, you can see that PyTuple_SetItem will raise a SystemError if the reference count is anything other than 1. So I think that it is only meant to be used with similar caution and restraint. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Tue, Jan 31, 2012 at 6:09 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Jan 31, 2012 at 5:53 PM, Chris Angelico ros...@gmail.com wrote: On Wed, Feb 1, 2012 at 9:03 AM, Duncan Booth duncan.booth@invalid.invalid wrote: Abitrarily nested tuples of exceptions cannot contain loops so the code simply needs to walk through the tuples until it finds a match. Is this absolutely guaranteed? The C API for CPython provides: (Py2) http://docs.python.org/c-api/tuple.html#PyTuple_SetItem (Py3) http://docs.python.org/dev/c-api/tuple.html#PyTuple_SetItem which doesn't have massive warnings on it saying USE THIS ONLY TO INITIALIZE A TUPLE (compare, for instance, _PyTuple_Resize which does carry a similar warning). Is the assumption then that we're all adults, and that mutating a tuple is like passing a null pointer to an API function (aka loaded gun in proximity to foot)? I don't know why the docs are written the way that they are, but if you check the code, you can see that PyTuple_SetItem will raise a SystemError if the reference count is anything other than 1. So I think that it is only meant to be used with similar caution and restraint. Incidentally, I *think* that any correctly written C code attempting to nest a tuple inside itself would make the reference count of the tuple be at least 2 at the time of the call, and so it would fail. -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Wed, Feb 1, 2012 at 12:12 PM, Ian Kelly ian.g.ke...@gmail.com wrote: Incidentally, I *think* that any correctly written C code attempting to nest a tuple inside itself would make the reference count of the tuple be at least 2 at the time of the call, and so it would fail. Good, nice that that's certain :) Might be worth moving the [b]ecause tuples are supposed to be immutable warning up to the top of the page then, since the bulk of it applies to all those functions and not just resize. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
Chris Angelico wrote: On Wed, Feb 1, 2012 at 9:03 AM, Duncan Booth duncan.booth@invalid.invalid wrote: Abitrarily nested tuples of exceptions cannot contain loops so the code simply needs to walk through the tuples until it finds a match. Is this absolutely guaranteed? The C API for CPython provides: (Py2) http://docs.python.org/c-api/tuple.html#PyTuple_SetItem (Py3) http://docs.python.org/dev/c-api/tuple.html#PyTuple_SetItem which doesn't have massive warnings on it saying USE THIS ONLY TO INITIALIZE A TUPLE (compare, for instance, _PyTuple_Resize which does carry a similar warning). Is the assumption then that we're all adults, and that mutating a tuple is like passing a null pointer to an API function (aka loaded gun in proximity to foot)? Unfortunately, I can't remember the details now, but I once set out to create a recursive tuple by using the C API, and it turned out then that the C API went to some lengths to prevent anyone being able to do that. I did finally do it in some peculiar way, but it wasn't simple. The c.l.python archives might still have the post where I described it. Mel. -- http://mail.python.org/mailman/listinfo/python-list
except clause syntax question
To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On 01/30/2012 06:41 PM, Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. Charles Yeomans Then, semantically, shouldn't it be a set? -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Jan 30, 2012, at 12:56 PM, Aaron wrote: On 01/30/2012 06:41 PM, Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. Charles Yeomans Then, semantically, shouldn't it be a set? Why, I suppose that would make even more sense. Charles Yeomans -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. I've always been perfectly fine with sometimes treating tuples as immutable sequences, so I'm +0 on saying more sense semantically, but given that the exception list can be a variable, I'm not sure what the gain is by keeping it immutable. #--- #!/usr/bin/env python # -*- coding: ASCII -*- '''Demonstrate catching variable exceptions. ''' def excepter (a, exceptions): try: 1.0/a 'Number ' + a except exceptions as e: print '!!! *** EXCEPTER CAUGHT ONE *** !!!' print repr (e) #~ excepter (0, [ZeroDivisionError]) excepter (0, (ZeroDivisionError,)) excepter (1, (ZeroDivisionError,TypeError)) excepter (1, (ZeroDivisionError,)) #--- excepter called with the list catches nothing, of course. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Mon, 30 Jan 2012 12:41:00 -0500, Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: Simplicity. If you also allow lists, then why not allow arbitrary sequences? What about iterators, do you allow them? That could be awkward, because iterators can only be run through once. Dictionaries are also iterable, so once you allow arbitrary iterables, you get dicts. The whole thing becomes a mess. Better to keep it simple and only allow a single canonical collection type, and in Python, that type is tuple, not list. Tuples are that canonical collection type because they have a number of desirable properties: - Tuples are small and memory efficient, using the smallest amount of memory needed to hold their items. Lists typically carry a block of spare memory, to make insertions fast. - Consequently the Python virtual machine can create them rapidly and efficiently. - Tuples are immutable, so you don't have to worry about passing one to a function and having the function modify it behind your back. - Tuples are ordered, for the times where that matters. - Since the typical use-case is to iterate over the items in fixed order, there's no need to pay the extra expense for a dict or set. - Tuples are simple to write: in general you only need commas between items. Sometimes, to avoid ambiguity or change the precedence of calculation, you also need round brackets (parentheses for Americans). Except clauses are one of those times. - Frozensets and sets are ruled out for historical reasons: they didn't exist until Python 2.3. Besides, which would you rather write? (abc, def) frozenset([abc, def]) - Sets and lists are ruled out because they are mutable, both require much more memory, and sets have a heavier computational burden. The latter makes more sense semantically to me -- catch all exception types in a list as opposed to catch this single thing composed of three exception types. Then you are labouring under a misunderstanding. You're not catching a tuple, because tuples are never thrown. You're catching any of the exceptions that are contained in that tuple. Both lists and tuples *are* single things in themselves. Both lists and tuples are containers: A list is a single thing that contains other things. A tuple is a single thing that contains other things. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Mon, Jan 30, 2012 at 7:00 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 30 Jan 2012 12:41:00 -0500, Charles Yeomans wrote: To catch more than one exception type in an except block, one writes except (A, B, C) as e: I'm wondering why it was decided to match tuples, but not lists: except [A, B, C] as e: Simplicity. -snip- I agree with the snipped, but would also like to add that regardless of why it might be so, tuples do appear to be the canonical type for collections that need to be typechecked -- not just for except; it's a consistent thing that if you're going to do something with X, or a bunch of X's, then it's either an X or a tuple of X's. For example, string formatting with % works this way, as does isinstance(a, X). -- Devin -- http://mail.python.org/mailman/listinfo/python-list
