On Friday 09 January 2004 06:32 am, Raymond Hettinger wrote: > I would like to establish a new module for some collection classes. Great idea. > a rich set of collection classes have proven their worth in other > contexts, it could be that more is not better for python. One the > language's elegances is the ability to do just about anything with > just lists and dicts. If you have too many mutable containers to > choose from, the choice of which to use becomes less obvious. Most uses will be excellently well met by lists and dicts, just like today. But just like today you sometimes find tuples or array.array's or sets.Set's serve your needs better, so might tomorrow a collections.Bag do so. The existence of sets.Set doesn't impede people from still using lists or dicts to represent sets as they did in the past, it just offer what may be a better way to programmers who _are_ familiar with the new facilities (and the concept of sets in the first place); collections.Bag will be just the same IMHO. In other words, I agree with you. > Likewise, queues are in a mental concept space distinct from dicts, > sets, and such. My only worry with queues is differentiating > them from Queue objects which have builtin synchronization for > use in threads. Maybe naming them Fifo rather than Queue, while less elegant, will make the distinction so sharp that no fear of confusion remains. Alex
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