[Python-Dev] PEP 431 Updates

[Nick Coghlan]

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