[Python-ideas] Adding collections.abc.Ordered

[Andrew Barnert]

On Nov 8, 2015, at 20:28, Guido van Rossum <guido at python.org> wrote:
> 
> So if OrderedDict had always rejected construction from a dict, how would you have written this?

Well, I wouldn't have written it this way in the first place. The obvious way to do it is to store the original headers and new headers separately. ChainMapping two dicts together is much more obvious than cramming them into one OrderedDict and keeping track of where the dividing index is. So, I'd do this:

    self.original_headers = copy.copy(headers)
    self.alt_headers = OrderedDict()
    self.headers = ChainMap(self.alt_headers, self.original_headers)

Now origheaders is just len(self.original_headers), altheaders is self.alt_headers.items().

I didn't make this change to the code in question because it worked, and had no edits for over 2 years, and it only took me a couple minutes to figure out what it was doing, so it made more sense just to leave it alone.

If Python 3.7 forced me to change it by not allowing OrderedDict to be constructed from a dict, I'd have to decide whether to make this change, or the obvious mechanical fix of just calling OrderedDict on iter(headers.items()) instead of headers to trick the Ordered check.

By the way, the fact that this simple mechanical workaround works, and provides no additional semantics to tell the reader what's going on, seems like a minor strike against the proposal. (And if you ban iterators too, I'd just change the iter(…) to list(…).) All Ordered can really check is that the type provides some way to preserve a meaningful order, not that the data really are meaningfully ordered, after all.

>> On Sunday, November 8, 2015, Andrew Barnert via Python-ideas <python-ideas at python.org> wrote:
>> On Nov 8, 2015, at 14:10, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> >
>> >> On 08.11.15 23:12, Sjoerd Job Postmus wrote:
>> >> On 8 Nov 2015, at 20:06, Amir Rachum <amir at rachum.com
>> >> <mailto:amir at rachum.com>> wrote:
>> >>> As part of BasicStruct I intend to allow the use of mapping types as
>> >>> __slots__, with the semantics of default values..
>> >>> So it'll look something like this:
>> >>>
>> >>>    class Point(BasicStruct):
>> >>>        __slots__ = {'x': 5, 'y': 7}
>> >>
>> >> So instead they'll write
>> >>     __slots__ = OrderedDict({'x': 5, 'y': 7})
>> >> Causing the same issues?
>> >
>> > Perhaps OrderedDict should reject unordered sources. Hey, here is yet one use case!
>> 
>> I've maintained code that does this:
>> 
>>     self.headers = OrderedDict(headers)
>>     self.origheaders = len(headers)
>> 
>> … so it can later do this:
>> 
>>     altheaders = list(self.headers.items())[self.origheaders:]
>> 
>> Not a great design, but one that exists in the wild, and would be broken by OrderedDict not allowing a dict as an argument.
>> 
>> Also, this wouldn't allow creating an OrderedDict from an empty dict (which seems far less stupid, but I didn't lead with it because I can't remember seeing it in real code).
>> 
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> -- 
> --Guido (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151109/f33eb03e/attachment.html>