On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano <steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
