> 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?
--
http://mail.python.org/mailman/listinfo/python-list
