Pythonification of the asterisk-based collection packing/unpacking syntax

Chris Angelico rosuav at gmail.com
Mon Dec 26 17:27:31 EST 2011


On Tue, Dec 27, 2011 at 8:51 AM, Eelco <hoogendoorn.eelco at 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



More information about the Python-list mailing list