Verbose and flexible args and kwargs syntax
- From: Eelco Hoogendoorn <hoogendoorn.eelco@xxxxxxxxx>
- Date: Mon, 12 Dec 2011 00:44:38 +0100
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.
.
- Follow-Ups:
- Re: Verbose and flexible args and kwargs syntax
- From: Jussi Piitulainen
- Re: Verbose and flexible args and kwargs syntax
- From: Steven D'Aprano
- Re: Verbose and flexible args and kwargs syntax
- Prev by Date: Re: unittest. customizing tstloaders / discover()
- Next by Date: Verbose and flexible args and kwargs syntax
- Previous by thread: Re: Verbose and flexible args and kwargs syntax
- Next by thread: Re: Verbose and flexible args and kwargs syntax
- Index(es):
Relevant Pages
|
