On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull <step...@xemacs.org> wrote: > Josiah Carlson writes: > > On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell <showel...@yahoo.com> wrote: > > > > What do you think of LISP, and "car" in particular (apart from > > > the stupidly cryptic name)? > > > Apples and oranges. > > True, but speaking of Lisp lists, here's some possibly relevant > experience. About 10 years ago, XEmacs converted its cons type from a > special immediate representation (ie, cons == (car, cdr)) to a generic > record representation (ie, cons == (pointer to type descriptor, car, > cdr)). This resulted in a perceptible increase in VM usage and disk > usage. A typical running XEmacs instance for me contains about 0.75 > million conses and uses 200MB of VM, so with 32-bit pointers that's > about 3MB extra, or 1.5%, and with 64-bit pointers it's 6MB extra, > about 3%. However, I tend to have several big buffers (20-50MB) of > pure character data; people who work with smaller buffers on 64-bit > machines have reported as much as 10% extra overhead. On disk, the > binary is typically about 9MB stripped. That contains about 50,000 > conses, or an extra 200KB/400KB with the new structure, somewhat more > than my experience (2% or 4%). > > Some people complained, but we considered this well worthwhile (moving > one "type bit" from the car to the header allowed Lisp integers to > cover the range -1G to +1G, and there are a surprising number of > people who would like to use XEmacs on files >512MB). I suppose that > Steve's proposal probably has similar impact on binaries and running > instances of Python, but he hasn't given any use cases for list.pop(0) > to compared to doubling the size of usable buffers.
The choice that emacs made is great for emacs; as you stated, it allowed emacs to do something it was previously unable to do. Steve H's proposed change would not allow Python to do anything it wasn't able to do before, and would (as TJR stated in this and other threads) saddle Python with overhead so as to make more convenient the use a structure for which it was not intended (paraphrased, of course). Again; no good use-case, means no problem, means no reason to try to solve the perceived "problem". It's great that you support Steve H's proposal, but can we keep the discussion on why this would be good for Python, rather than why changing a structure that is identical in name (but only similar in functionality) to Python's list was good for another language? - Josiah _______________________________________________ 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
