[Raymond Hettinger]
I am frankly surprised that so many here think that a collections module would be bad for the language. Go figure. It's not like these are new, untried ideas -- the goal was supposed be improving productivity by providing higher level tools. A fast underlying implementation was just icing on the cake.
I think the "fast implementation" issue has triggered people's comments, rather than the "higher level tools" one.
For the record, I'm +1 on the idea (as far as "higher level tools" goes). I'm not too bothered, in practice, how efficient the implementation is, as long as it's not visibly slower than using lists/dicts directly :-)
I may be the source of some of this kind of feedback. My main concern is that when we offer too many fast (*fast*!) data types competing with list and dict, inexperienced users will more easily be mislead into picking the wrong data type for their application, simply by the overwhelming choices. Something that advertises itself as *fast*! is incredibly attractive to many people who have absolutely no need for it -- just like automobiles that can go several times the speed limit. I'm not worried about the absolute newbies -- they will read the tutorial and use the training wheels provided by the examples. It's the middle tier of programmers who have very little understanding of algorithm complexity (that small amount of knowledge that can be such a dangerous thing) but are excited by all the new and wondrous stuff hidden in the standard library. Marking it with danger signs or "advanced use only" will have the inverse affect -- these are even more attractive than speed claims. Remember Knuth: the root of all evil lies in premature optimization. --Guido van Rossum (home page: http://www.python.org/~guido/)