Arithmetic sequences in Python

Alex Martelli aleax at mail.comcast.net
Thu Jan 19 01:55:19 EST 2006


Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
   ...
> What should the output of "print list(1,2,3)" be?  Is there a really
> good reason to make it different from the input syntax?

If we assume that str and repr must keep coinciding for lists (and why
not), no reason -- just like, say, today:

>>> print set([1,2,3])
set([1, 2, 3])

input and output could be identical.  Do YOU have any good reason why
sets should print out as set(...) and lists should NOT print out as
list(...)?  Is 'list' somehow "deeper" than 'set', to deserve a special
display-form syntax which 'set' doesn't get?  Or are you enshrining a
historical accident to the level of an erroneously assumed principle?

> What should list(list(1,2,3)) be?  Should "list" really work
> completely differently depending on whether it has a single arg or
> multiple args?

It works just fine for max and min, why should list be different?

> How would you make a one-element list, which we'd currently write as [3]?
> Would you have to say list((3,))?

Yep.  I don't particularly like the "mandatory trailing comma" in the
tuple's display form, mind you, but, if it's good enough for tuples, and
good enough for sets (how else would you make a one-element set?), it's
good enough for lists too.  If we can find a nicer singleton-form, let's
apply it uniformly to all genexps, and list(<niceform>) will be fine!-)


> > I see no credibly simple and readable alternative to {a:b, c:d}
> > dictionary display syntax, for example; dict(((a,b),(c,d))) just
> > wouldn't cut it, because of the "parentheses overload" (double
> > entendre intended).
> 
> dict(a=b,c=d)
> 
> I don't really see why keyword arg names have to be identifiers
> either.  foo(3=4) can pass a **kwargs containing {3:4}.

I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
'c':d} -- it's much more congruent to how named arguments work for every
other case.  Would you force us to quote argument names in EVERY
functioncall...?!


> > But list has no such problem, and there's really no added value of
> > clarity and readability in [a,b,c] vs list(a,b,c).
> 
> That's subjective at best.  Even Scheme doesn't make you use
> extra keywords to write something as fundamental as a list.  ;-)

In Python, a list is no more fundamental than a dict or a set (in maths,
I guess a set IS more fundamental, of course, but Python's not
necessarily congruent to maths).  Only tuples deserve special treatment
on semantical grounds (as they're used to pass multiple arguments to
functions or return multiple values for function).  Of course "it's
subjective" -- obviously, some people prize conciseness above everything
else (otherwise APL and its successors would have been stillborn),
others prize verbosity (or else Cobol would never have been coinceived);
but Python's "Middle Way" tends to strike a good balance.  IMHO, the
balance would be better served by spelling list(1,2,3) rather than
[1,2,3] (but the BDFL disagrees, so my opinion doesn't matter much).

 
> > So the only reason they may "suggest lists" is that you're used to
> > that display form in Python, but there's no real reason to HAVE a
> > display form for lists at all, IMHO.
> 
> Well, what's supposed to happen when you print a list then?

Just the same as when you print a set: <typename>(<args>).


Alex



More information about the Python-list mailing list