I found a use case, out in the wild! I've been searching through GitHub for "ordered" and similar phrases. Much of the usage is OrderedDict and OrderedSet, which really don't benefit from an essentially redundant inheritance from a hypothetical collections.Ordered. There are some tools that enable UI reordering, and a bunch of tree- and graph-traversal ordering functions. Again, not much benefit from a collections.Ordered. However, Django has a class factory that creates an attribute `can_order`: def formset_factory(form, formset=BaseFormSet, extra=1, can_order=False, can_delete=False, max_num=None, validate_max=False, min_num=None, validate_min=False): """Return a FormSet for the given form class.""" if min_num is None: min_num = DEFAULT_MIN_NUM if max_num is None: max_num = DEFAULT_MAX_NUM # hard limit on forms instantiated, to prevent memory-exhaustion attacks # limit is simply max_num + DEFAULT_MAX_NUM (which is 2*DEFAULT_MAX_NUM # if max_num is None in the first place) absolute_max = max_num + DEFAULT_MAX_NUM attrs = {'form': form, 'extra': extra, 'can_order': can_order, 'can_delete': can_delete, 'min_num': min_num, 'max_num': max_num, 'absolute_max': absolute_max, 'validate_min': validate_min, 'validate_max': validate_max} return type(form.__name__ + str('FormSet'), (formset,), attrs) This attribute gets set in several places, but checked only twice in the Django codebase. Unfortunately, I think switching to the proposed inheritance mechanism would make the code worse, not better: `self.can_order` would become `isinstance(self, collections.Ordered)`. The readability of the Django internal code would not be much different, but users would lose consistency of introspectability as the other features like `can_delete` are simple class attributes. On Mon, Nov 9, 2015 at 11:29 AM, Guido van Rossum <guido@python.org> wrote:
Well, that would still defeat the purpose, wouldn't it? The items are no more ordered than the headers dict itself. Also, items() doesn't return a sequence -- it's an ItemsView (which inherits from Set) and presumably it's not Ordered.
I guess my question is not so much how to prevent getting an exception -- I'm trying to tease out what the right order for the headers would be. Or perhaps I'm just trying to understand what the code is doing (the snippet shown mostly looks like bad code to me).
On Mon, Nov 9, 2015 at 12:03 AM, Ram Rachum <ram@rachum.com> wrote:
I'm not Andrew, but I'm guessing simply writing `OrderedDict(headers.items())`.
On Mon, Nov 9, 2015 at 6:28 AM, Guido van Rossum <guido@python.org> wrote:
So if OrderedDict had always rejected construction from a dict, how would you have written this?
On Sunday, November 8, 2015, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Nov 8, 2015, at 14:10, Serhiy Storchaka <storchaka@gmail.com> wrote:
On 08.11.15 23:12, Sjoerd Job Postmus wrote: On 8 Nov 2015, at 20:06, Amir Rachum <amir@rachum.com <mailto:amir@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/