[Python-ideas] Adding collections.abc.Ordered

[Wes Turner]

"[Python-ideas] OrderedCounter and OrderedDefaultDict"
https://mail.python.org/pipermail/python-ideas/2015-November/037163.html

- +2 for collections.ABC.Ordered
- exception on initialization w/ an unordered collection ///
__init__force_from_unordered
On Nov 9, 2015 7:21 PM, "Michael Selik" <mike at selik.org> wrote:

> 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 at 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 at 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 at 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 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)
> >>>
> >>> _______________________________________________
> >>> 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 van Rossum (python.org/~guido)
> >
> > _______________________________________________
> > 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/
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151226/e856572e/attachment-0001.html>