Hm, this just indicates whether some UI appears by which the user can reorder the forms in a list? Is it even appropriate to move this from the instance to the class?

On Mon, Nov 9, 2015 at 4:20 PM, Michael Selik <mike@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@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/



--
--Guido van Rossum (python.org/~guido)