On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > 3128 (BList) -- I'll leave this for Raymond Hettinger to review. > > After looking at the source, I think this has almost zero chance for replacing > list(). There is too much value in a simple C API, low space overhead for > small lists,
Thanks for taking time to review my code. Did you look through the PEP as well? Both of these issues were specifically addressed. In fact, I am half way done with implementing the change so that small BLists are memory efficient. > good performance is common use cases, This is also addressed, to some extent, in the PEP. > and having performance that is easily understood. I am not sure what aspect of the performance might be misunderstood. Just about everything is O(log n). Could you clarify your concern? > The BList implementation lacks these virtues and trades-off a little > performance > is common cases for much better performance in uncommon cases. As a Py3.0 > PEP, I think it can be rejected. Would it be useful if I created an experimental fork of 2.5 that replaces array-based lists with BLists, so that the performance penalty (if any) on existing code can be measured? > Depending on its success as a third-party module, it still has a chance for > inclusion in the collections module. The essential criteria for that is > whether > it is a superior choice for some real-world use cases. I've scanned my own > code and found no instances where BList would have been preferable to a > regular list. However, that scan has a selection bias because it doesn't > reflect > what I would have written had BList been available. Indeed, I wrote the BList because there were idioms that I wanted to use that were just not practical with an array-based list. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
