Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 28, 8:08 am, Chris Angelico <ros... at gmail.com> wrote:
> On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
>
>
>
>
>
>
>
>
>
> <steve+comp.lang.pyt... at pearwood.info> wrote:
> > On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
> >> ... suppose you have a huge
> >> set/frozenset using tuples as the keys, and one of your operations is to
> >> shorten all keys by removing their first elements. Current Python
> >> roughly doubles the cost of this operation, since you can't choose what
> >> type the tail is made into.
>
> > The First Rule of Program Optimization:
> > - Don't do it.
>
> > The Second Rule of Program Optimization (for experts only):
> > - Don't do it yet.
>
> > Building syntax to optimize imagined problems is rarely a good idea. The
> > difference between 2 seconds processing your huge set and 4 seconds
> > processing it is unlikely to be significant unless you have dozens of
> > such huge sets and less than a minute to process them all.
>
> > And your idea of "huge" is probably not that big... it makes me laugh
> > when people ask how to optimize code "because my actual data has HUNDREDS
> > of items!". Whoop-de-doo. Come back when you have a hundred million
> > items, then I'll take your question seriously.
>
> > (All references to "you" and "your" are generic, and not aimed at Chris
> > personally. Stupid English language.)
>
> And what you're seeing there is the _best possible_ situation I could
> think of, the strongest possible justification for new syntax.
> Granted, that may say more about me and my imagination than about the
> problem, but the challenge is open: Come up with something that
> actually needs this.
>
> ChrisA

I personally feel any performance benefits are but a plus; they are
not the motivating factor for this idea. I simply like the added
verbosity and explicitness, thats the bottom line.