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