On Dec 26, 11:27 pm, Chris Angelico <ros...@gmail.com> wrote: > On Tue, Dec 27, 2011 at 8:51 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote: > > That proves the original point of contention: that [Steve's demo code] is > > suboptimal language design, not because terseness always trumps > > verbosity, but because commonly-used constructs (such as parenthesis > > or round brackets or whatever you wish to call them) are more > > deserving of the limited space in both the ascii table and your > > reflexive memory, than uncommonly used ones. > > In Magic: The Gathering R&D, they have a term (the article reporting > which I can't actually find at the moment) called "spread complexity" > or "fan complexity" - the idea being that as you fan out a booster > pack, you see a certain amount of complexity in front of you. The > designers can afford to put more complex cards in as rares than they > can as commons, because you see ten commons for every rare - so a > common factors ten times as much as a rare in spread complexity. (Mark > Rosewater, my apologies if I'm misremembering here!) > > The same applies here. When you cast your eye over a program, you're > going to see certain syntactic elements a lot. Assignment, arithmetic, > blocks of code (ie indent/dedent), and function calls are all > extremely common; lambdas, the use of decorators, and exception > handling are somewhat uncommon; and metaclasses, the writing of > decorators, and reloading of modules are all quite rare. > > The elements that occur frequently should be: > a) Readable and grokkable; > b) Easily typed on a regular keyboard - no using ASCII character 126 > to mean negation, tyvm! > c) Make sense. > > Rarer elements (and I'm not talking about xenon and plutonium here) > are allowed to have long names, obscure syntax, or even be shoved away > in odd modules (the way module reloading is in Python 3). If 0.1% of > your code is suddenly twice as large as it used to be, will you > notice? But if a new syntax adds even 5% to the mindspace requirement > of basic assignment, your code will majorly suffer. > > In summary: Terseness trumps verbosity primarily for common > operations, and only when doing so does not violate rules a and c > above. > > ChrisA
Good to see there is something we agree upon completely. Not that I mean to say the question as to how verbose a syntax is appropriate for collection (un)packing is settled; one could reasonably argue they find tail::tuple too verbose. But parenthesis are not a terribly good example to compare to, since they are infact so much more used they are clearly in another category. *args and **kwargs are debateable in the appropriateness of their terseness (but I personally like to err on the side of verbosity), but extended collection unpacking, as in 'head,*tail=sequence', is quite a rare construct indeed, and here I very strongly feel a more explicit syntax is preferrable. That is, as a seasoned python 2 user, I wouldnt have been willing to gamble on what this does when id come across it for the first time in python 3. Could as well be a completely new use of the asterisk. But if collection packing/unpacking would be presented as a more general construct from the start, 'head,tail::tuple=sequence' would be hard to miss. -- http://mail.python.org/mailman/listinfo/python-list
