[Python-Dev] Re: collections module
Guido van Rossum
guido at python.org
Mon Jan 12 14:46:24 EST 2004
> > [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/)
More information about the Python-Dev
mailing list