Having read the entirety of the thread (which is a rare case these days, I need more spare time), and being that I'm feeling particularly snarky today, I'm going to agree 100% with everything that Raymond has said in this message and his few subsequent messages. Snarky comments to follow.
I would also point out that the way these things are typically done is that programmers/engineers have use-cases that are not satisfied by existing structures, they explain the issues they have with existing structures, and they propose modifications. So far, Steve has not offered any use-cases for why his proposed change is necessary; merely a (paraphrased) "It would be great if list.pop(0) was O(1) instead of O(n)." It's a solution looking for a problem that doesn't exist. That said, even if he were to magically come up with twenty examples where neither a deque nor a list were the right solution, I'd still be a -10000, because in the decade+ that I've been using Python and needed an ordered sequence; lists were the right solution 99% of the time, deques got .99%, and the remaining .01% would not have been satisfied with what Steve is proposing (this is obvious hyperbole and made-up numbers, but the number of sequence types I've created (easily 10-20) is still a few orders of magnitude lower than how often I use plain lists and deques). Don't get me wrong, I'm all about nifty "optimizations" (I still get a chuckle out of proper string lengths with surrogate pairs, string views, "Some", ...). But in this case there is no problem; merely the use of a data structure for something it was not designed. It's great that Steve wants to help. And I <3 innovation in data structures. But this patch isn't innovation, and it isn't helping 99.99% of use-cases. </snark> Going back to not having free time, - Josiah On Tue, Jan 26, 2010 at 1:52 PM, Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > > Ah, but that applies for *large* lists. Adding 8 bytes to > > each list > > object applies to *all* lists. I betcha that many programs > > use many > > tiny lists. > > > Even most tiny-ish lists are wasting memory, though, according to this > sequence: > > 4, 8, 16, 25, ... > > > That is only is they are being grown with list.append(). > Otherwise, list sizes are exact. For example, [0,1,2] > uses space for just three entries and [] for none. > I get the impression that 1) you've already made up your > mind and are ignoring input from the other developers, > 2) that you're ignoring the python-dev discussions of long ago > where this very idea was rejected and deques came in to > being instead, 3) over-estimating the prevalence of use > cases for pop(0), and 4) under-estimating the impact on > small lists, 5) under-estimating the impact on psyco or > other implementations of Python, 6) under-estimating the > impact on third-party extensions and debugging tools. > Deques already provide a solution to the FIFO problem > and they do so without huge wastes of memory or calls > to memmove(). They handle both insertion and deletion > from the front and back. In comparison, the proposed > changes to lists seem like a complete hack. Just because > it can be done, doesn't mean that it should. > ISTM that you're attacking an already solved problem > and that you're playing fast and loose with a core data > structure. > > Raymond > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
