Josiah Carlson writes:
 > On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull
 > <step...@xemacs.org> wrote:

 > > 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;

Emacs hasn't made that choice, XEmacs did.  I believe Emacs is still
"restricted" to 128MB, or maybe 256MB, buffers.  They recently had an
opportunity to increase integer size, and thus maximum buffer size,
but refused it.  It's not a no-brainer.

 > It's great that you support Steve H's proposal, but can we keep the
 > discussion on why this would be good for Python,

I don't support it or oppose it (I wouldn't notice the increased
overhead myself, but I have no use case for O(1) list.pop(0)).  I'm
giving some figures on a similar change (adding a single pointer to a
previously low-overhead structure used in large numbers in some
applications), and pointing out that this was good for XEmacs only
because there was a rather big increase in capability in a use-case
that people can sympathize with even if they don't need it themselves.

I hope that this example will help Steve H understand why he needs to
give real use-cases, or if he doesn't know of any, give up.

_______________________________________________
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

Reply via email to