Pythonification of the asterisk-based collection packing/unpacking syntax

Eelco hoogendoorn.eelco at gmail.com
Wed Dec 28 07:04:00 EST 2011


On Dec 28, 12:07 am, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> On Mon, 26 Dec 2011 13:51:50 -0800, Eelco wrote:
>
> [...]
>
> >> If your point is that parens are used more often than
> >> packing/unpacking, that's almost certainly true, since function calls
> >> (including method invocations) are so prevalent in pretty much any
> >> code. But what does that prove?
>
> > That proves the original point of contention: that the below* is
> > suboptimal language design,
>
> Well duh.

This is where the referee should interrupt you for snipping someones
citation right before a 'but'

> I was mocking the idea that the meaning of * is context-dependent is a
> bad thing by pointing out that we accept context-dependent meaning for
> round brackets () without any difficulties. Of course it is "suboptimal
> language design" -- it couldn't fail to be. Context-dependency is not
> necessarily a bad thing.

You know, so you dont end up simply restating my point while trying to
make it seem like you disagree.

> > not because terseness always trumps
> > verbosity, but because commonly-used constructs (such as parenthesis or
> > round brackets or whatever you wish to call them)
>
> Parentheses are not a construct. They are symbols (punctuation marks)
> which are applied to at least three different constructs: grouping,
> function calls, class inheritance lists.

Parenthesis encompass a class of constructs. Happy now?

> > are more deserving of
> > the limited space in both the ascii table and your reflexive memory,
> > than uncommonly used ones.
>
> Right. And since sequence packing and unpacking is a common idiom, it
> deserves to be given punctuation. That's my opinion.

Its a valid opinion. But if we are going to be quantitative about
terms such as 'common', you know that there will be at least an order
of magnitude difference between these constructs in commonality, if
not two. Thats what makes your example a poor one. If you could
verbosify a construct of the same commonality and arrive at equally
absurd code, you would have a point.



More information about the Python-list mailing list