[Python-talk] Reflections on tuples, September 2005, 2 of 2

Python python at venix.com
Fri Sep 23 22:41:43 EDT 2005


I think trailing commas are tolerated rather than encouraged.  Only the
single element tuple is forced to have a trailing comma.  Allowing a
trailing comma makes it easier to extend sequence later.

http://python.org/doc/2.3.5/ref/exprlists.html

This is from the 
Language Reference 
(for language lawyers)

Just being nit-picky, but if you are dealing with a class, it is
sometimes easier when you are precisely right.


On Fri, 2005-09-23 at 18:00 -0400, Bill Sconce wrote:
> 
> ----------------------------------------
> PySIG September 2005
> Tuple Snippets, 2 of 2
> We don't need no stinkin' parentheses
> ----------------------------------------
> 
> A real clarification!  For someone like me, who teaches Python,
> just one jewel such as this makes going to a meeting worthwhile.
> 
> We were discussing how parentheses seem to have two different, 
> confusing uses:  to indicate tuples and to group things.  Lloyd said, 
> almost in passing "No, it's not parentheses which signify a tuple.
> It's COMMAS."
> 
> Huh?
> 
>   ***head scratching***
> 
>   ***more head scratching***
> 
> Bingo!
> 
> _______________________________________________________________________
> 2.  A comma's meaning does depend on the context, and we admit that
> commas don't always signify a tuple.  But commas are NECESSARY to
> signify a tuple.  Parentheses aren't!
> 
> Each of these snippets can be typed in in less than 10 seconds.
> 
> >>> three_numbers = [1, 2, 3]
> >>> three_numbers
> 
> >>> [a, b, c] = three_numbers
> >>> a
> >>> b
> >>> c
> 
> >>> (d, e, f) = three_numbers
> >>> d
> >>> e
> >>> f
> 
> >>> g, h, i = three_numbers
> >>> g
> >>> h
> >>> i
> 
> >>> three_other_numbers = 4, 5, 6
> >>> three_other_numbers
> 
> >>> j, k, m = three_other_numbers
> >>> j
> >>> k
> >>> m
> 
> >>> n, o, p = 7, 8, 9
> >>> n
> >>> o
> >>> p
> 
> >>> q, r = 10, 11
> >>> q
> >>> r
> 
> -------------------------------------------
> In passing, the canonical "swap" idiom:
> -------------------------------------------
> 
> >>> r, q = q, r
> >>> q
> >>> r
> 
> -------------------------------------------
> Home stretch...
> -------------------------------------------
> 
> >>> two_element_sequence = [12, 13]
> >>> one_element_sequence = [42]
> >>> one_element_sequence
> >>> two_element_sequence
> 
> >>> t, u = two_element_sequence
> >>> t
> >>> u
> 
> >>> v, = one_element_sequence
> >>> v
> 
> >>> w, x = 14, 15
> >>> w
> >>> x
> 
> -------------------------------------------
> And finally:
> -------------------------------------------
> 
> >>> y = 42,
> >>> y
> 
> --------------------------------------------------------------------
> Q.E.D.
> It's the comma which denotes the tuple.  Parentheses, although often
> necessary to group things (or often desirable to help readability, 
> as when the interpreter DISPLAYS a tuple) have nothing to do with
> tuple-ness.  The  commas, however, are NOT optional.
> 
> ====================================================================
> Footnote - further refelection:  striving for a concise, consistent
> pedagogy about tuple syntax...
> 
> The one-element tuple has always been hard to teach.  You show
> a student:
> 
>     (a, b, c)        is a tuple    
>     (d, e)           is a tuple
>     
> and the student nods, thinking "I see. Parentheses denote tuples".
> 
> Then you have to explain that
> 
>     (f,)             is a one-element tuple
>     
> and everyone's uncomfortable.  You and the student both think that
> this use of a comma looks like a kluge, a special case, since the
> student is thinking about the parentheses.
> 
> What I'll teach from now on is
> 
>      a, b, c,        is a tuple(*)
>      
> and that parentheses are used ONLY to group things (**).
> 
> So now,
> 
>      a, b, c,        is a tuple
>      d, e,           is a tuple
>      f,              is a tuple
> 
> Kluge no more.
> 
> 
> 
> __________________________________________
> (*)  a, b, c,         is a tuple...
> 
> ...IF the context is suitable.  More generally, "a, b, c," could
> be a sequence (for instance, if the context is enclosure by brackets
> it may be a list).  Or with braces a dictionary.  Or...
> 
> It remains true that there's an asymmetry.  
>             
>    1. in many contexts we allow omission of the final trailing
>       comma, e.g.,
>       
>             (a, b, c)    for  (a, b, c,)
>             (d, e)       for  (d, e,)
>             
>       and
>       
>             [a, b, c]    for  [a, b, c,]
>             [d, e]       for  [d, e,]
>             
>       and
>       
>             {'u': 'ewe', 'v': 'vee'} for {'u': 'ewe', 'v': 'vee',}
>             
>       and that we actually do write code either with or without the
>       final trailing comma depending on such things as maintainability
>       of multi-line continuations
> 
> 
>    2. in some contexts the final trailing comma can still be omitted 
>       even when it's the ONLY comma:
>       
>             [f]           for    [f,]
>             {'u': 'ewe'}  for    {'u': 'ewe',}
> 
> 
>    3. but omitting the final trailing comma is NOT possible in the one
>       significant case of the one-element tuple.  ITS context allows
>       no clue as to tuple-ness other than the comma:
>       
>             f,      # a one-element tuple - good
>             
>             f       # is a scalar - not a tuple
>             
>  
> In any case, none of this has anything to do with parentheses.
> 
> 
> _____________________________________________________________
> (**) and that parentheses are used ONLY to group things (**).
> 
> I _think_ we can get by with this, if "group things" can be
> taken to include grouping things for precedence of operations,
> specifying formal parameters for definitions of functions & 
> classes, etc., and passing parameters to an invocation.  
> 
> Comments welcome.
> 
> _______________________________________________
> Python-talk mailing list
> Python-talk at dlslug.org
> http://dlslug.org/mailman/listinfo/python-talk
-- 
Lloyd Kvam
Venix Corp



More information about the Python-talk mailing list