> > [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. > [...] [Guido] > > 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. [Paul] > 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. That sounds reasonable. I think set and frozenset should also be moved into this new module then. (That would also make it easier for someone to provide a backwards compatible version for Python 2.3 and before as a 3rd party add-on.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4