On Sun, Sep 21, 2014 at 02:37:39PM +1000, Steven D'Aprano wrote:
In 2007, this PEP was created that suggested integrating Daniel Stutzbach's blist into Python: http://legacy.python.org/dev/peps/pep-3128/
The PEP was rejected, but Raymond Hettinger made a note that "after a few months, I intend to poll comp.lang.python for BList success stories. If they exist, then I have no problem with inclusion in the collections module."
I have not used blist, but I have no objection to it becoming a collections type if the author agrees.
It seems unsettling that we'd consider adding another special use collection to the stdlib, when more widely applicable generalizations of it are missing. In blist's case, it can (mostly) be trivially reimplemented using an ordered map, which the standard library lacks. The remainder of blist (IIRC) are some fancy slicing and merging methods that exploit the underlying structure. Even after reviewing the original PEP, the presence of OrderedDict (and particularly under that moniker) feels wrong. Since its addition, in every case I've encountered it in commercial code, the use has been superfluous, diabolically miscomprehended, or used as a hacky stand-in for some cleaner, simpler approach. Coming from this perspective, I'd prefer that further additions were limited to clean and far better understood structures. In this light, could we perhaps instead discuss the merits of a collections.Tree, collections.SortedDict or similar?
which makes blist an optimization, if and when it is available.
blist has functionality that would require significant boilerplate to replicate in normal code, so it's definitely not just useful as an optimization. David