Guido van Rossum <guido@python.org> writes:
[Raymond Hettinger]
I am frankly surprised that so many here think that a collections module would be bad for the language. [...] I think the "fast implementation" issue has triggered people's comments, rather than the "higher level tools" one. [...] 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.
Agreed. I think that simply creating a module called "collections", advertised as containing "a variety of data structures designed to handle collections of data" should be enough. Low-key enough to avoid being an attractive nuisance, accurately-named enough that people should find it easily enough if they need it. Add an "efficiency" section to the documentation, if it matters that much (and if so, I'd suggest that memory use be addressed as well as speed...) In my experience, though (assuming I classify in the not-newbie-but- not-expert-either category...), I prefer data types built into the language over ones in modules, unless there is a clear need to go further. For example, the mere fact that re is a module persuades me to save it for cases where it's really needed - I use string methods like startswith and find much more than I ever would in Perl, where REs are built in. This is a good thing - REs are too much of an "attractive nuisance" in Perl. I'd expect the same to be true with the collections module. I'd tend to use lists and dictionaries as my first choice, saving collections for cases where I really need them. So, if my perception is typical, I don't think there will be that big an issue. Paul. -- This signature intentionally left blank