Verbose and flexible args and kwargs syntax

[Eelco Hoogendoorn]

 > No more, or less, explicit than the difference between "==" and "is".

== may be taken to mean identity comparison; 'equals' can only mean one 
thing. Of course 'formally' these symbols are well defined, but so is 
brainf*ck

>  Modulo is hardly an obscure operation. "What's the remainder...?" is a
>  simple question that people learn about in primary school.


So is 'how much wood would a woodchucker chuck if a woodchucker could 
chuck wood?'. But how often does that concept turn up in your code?

 > And you can blame C for the use of % instead of mod or modulo.

I didnt know one of Python's design goals was backwards compatibility 
with C.

>  I can't imagine what sort of Python code you have seen that you consider
>  90% attribute access "typical". I've just run the Python tokenizer over
>  my startup.py file, and I get these results:

Yes, that was a hyperbole; but quite an often used construct, is it not?

>  If you can supply any function at all, what happens if I write this:


You cannot; only constructors modelling a sequence or a dict, and only 
in that order. Is that rule clear enough?

 > I believe that your proposal leads to an over-generalisation "call
 > arbitrary functions when handling parameter lists".

I hope the above clears that up. It is as much about calling functions 
as ** is about raising kwargs to the power of.

 > I don't believe you
 > need this added complication. If you want to your var args as a list,
 > call list(args) inside your function.

We dont strictly 'need' any language construct. Real men use assembler, 
right?


>  >/  head, tuple(tail) = iterable
/>  In Python 3, that is spelled:
>  head, *tail = iterable
>  tail = tuple(tail)

Yes, I know. How is that not a lot more verbose and worse than what I 
have proposed in all possible ways?

 > head, tail = somestring[0], somestring[1:]

Well yes, splendid; we can do that with lists too since the dawn of 
Python. What you are saying here in effect is that you think the 
head/tail syntax is superfluous; that youd rather see it eliminated than 
generalized.

 > head, tail = next(mygenerator), mygenerator

Which again of course works, but is yet again of entirely different form 
than any of the above solutions, while conceptually doing the same 
thing. Certainly, there is room for improved elegance here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20111212/74b1c8a5/attachment.html>