Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!news-transit.tcx.org.uk!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Mon, 12 Dec 2011 00:44:38 +0100
From: Eelco Hoogendoorn <hoogendoorn.eelco@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Verbose and flexible args and kwargs syntax
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3520.1323647085.27778.python-list@python.org>
Lines: 79
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:16993

>  No more so than any other form of punctuation. Plus and minus + - may be
>  so common that just about everyone knows it, but how about | == @ % and
>  even . (dot)? None of these things will be obvious to newbies who have
>  never programmed before. Oh well.

>  Some things you just have to learn.


Yes, some things you just have to learn. Nonetheless, I strongly prefer 
explicit logical operators over |, would much rather have 'equals' 
instead of ==, which is stylistic in line with 'is' and explicitly 
distinguishes between equality and identity comparisons. As for %; it is 
entirely unclear to me why that obscure operation ever got its own 
one-character symbol. Ill take 'mod', or even better, 'modulus' any day 
of the week.

The dot is clearly quantitatively in another realm here. 90% of typical 
python code is attribute accesses. The dot is entirely unambigious and 
cannot be mistaken for anything else. It reads like a book.

>  It's a judgement call as to where a language divides "cryptic punctuation
>  line noise" and "useful short operators", and in my opinion * and ** tuple
>  and dict unpacking fall strongly on the "useful short operators" side.
>  Your opinion may differ, but luckily for me, the BDFL agrees with me :)

I also agree that it is a value judgement as to which constructs get 
their own cryptic symbols and which do not, but the are some reasonable 
guidelines we should be able to agree upon. Obscure operations should 
not reserve any of the few available characters. Furthermore, the 
language should not just be formally consistent, but also easy to grasp 
at a glance, without deciphering subtle semantics of a blurb of weird 
characters. (some programming languages obviously disagree, but python, 
as far as I am allowed to speak for it, does not). And most importantly, 
if you cant come up with a terse syntax that does everything you want to 
do, the terse syntax should at best be an alternative to the verbose one.


>  It is also misleading because args are not collected into a list, but
>  into a tuple.

In case you wanted a tuple youd write tuple(args), obviously. Exactly that added flexibility is half of my case in favor. Why shouldnt it be a list when I want it to?



>  Worse, it suggests that one should be able to generalise to
>  something like this:

>  def func(parg, str(args), int(kwargs), my_func(more_args)):

>  which is incoherent.

Sorry, but I dont get this point at all. Does ** suggests one should be 
able to generalize to ***? The rules are the rules.



The real questions, in my mind, are:

1) How useful is this added flexibility? Not insanely, but I can see it 
making a lot of code significantly more clean.

And:

2) How fundamental is collection packing/unpacking? One can easily argue 
that it is indeed quite fundamental and therefore deserves its own terse 
symbols, I feel. However, if more flexibility is indeed deemed 
desirable, such terse syntax quickly gives way to a more verbose one. 
Can you come up with some terse symbols that will be able to express all 
of the below and dont make you wish you hadnt rather typed out the names?

head, tuple(tail) = iterable
head, list(tail) = iterable
head, str(tail) = somestring
head, generator(tail) = mygenerator

And so on.

If not, one has to admit that functionality is being sacrificed on the 
alter of terseness, which seems like a raw deal to me.