Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 26, 11:27 pm, Chris Angelico <ros... at gmail.com> wrote:
> On Tue, Dec 27, 2011 at 8:51 AM, Eelco <hoogendoorn.ee... 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

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.