RE: [Python-Dev] collections module
From: 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 :-) Paul.
[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/)
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
[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/)
participants (3)
-
Guido van Rossum -
Moore, Paul -
Paul Moore