[Python-Dev] PEP 431 Updates (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Jan 28 14:12:00 CET 2013

On Mon, Jan 28, 2013 at 10:52 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

Le Mon, 28 Jan 2013 22:31:29 +1000, Nick Coghlan <ncoghlan at gmail.com> a écrit :

>> 6. Under "New collections" >> >> Why both lists and sets? > > Because pytz did it. But yes, you are right, an ordered set is a > better solution. Baseing it on OrderedDict seems like a hack, > though. I could implement a custom orderedset, of course. Sets themselves have an honourable history of just being a thin wrapper around dictionaries with all the values set to None (although they're not implemented that way any more). Whether you create an actual OrderedSet class, or just expose the result of calling keys() on an OrderedDict instance is just an implementation detail, though. Why the complication? Just expose a regular set and let users call sorted() if that's what they want. I'm -1 on datetime shipping its own container subclass just for the sake of looking clever.

I was going by the fact that pytz decided to expose both, and it isn't clear whether the "fast containment test" or "lexically ordered iteration" should be the base behaviour if you're going to rely on sorted() or set() to convert between the two. Since OrderedDict can provide both, creating one internally and just exposing keys() makes sense to me (perhaps via types.MappingProxyType to make it read-only).

If people really don't like using OrderedDict that way, I think the other two potentially sensible options are either using an ordinary set, or else adding collections.OrderedSet. I agree adding a new ordered set type hidden within datetime would be a poor idea.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list