On Dec 28, 8:08 am, Chris Angelico <ros...@gmail.com> wrote: > 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
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. -- http://mail.python.org/mailman/listinfo/python-list
