[Python-ideas] Adding collections.abc.Ordered

[Stephen J. Turnbull]

Guido van Rossum writes:

 > 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.

If they are email headers, then each MTA is supposed to *prepend* its
trace fields (Received and friends) to the existing header block.
Those new fields would correspond to Andrew's "alternate" headers.

Perhaps you are thinking of the fact that MTAs are also supposed to
preserve the existing order of headers.  However, the mail system as a
whole is in practice not reliable because of intermediating agents
like mailing lists and user forwarding.  These sometimes insert
application fields (such as List-* and Resent-*) before the trace
fields block rather than prepend their fields to the existing header.
As an indication of this lack of reliability, DKIM does not prescribe
a set or block of fields to sign, but rather the fields to sign are
specified as a sequence in the DKIM-Signature header, and verifiers
must extract and append the fields to the content to be signed in that
order regardless of physical order.

Python's email package provides a header abstraction which is an
ordered mapping.  The point is to be able to reproduce the entire
message with full accuracy by Message.flatten() (ie, without affecting
signatures).  So the relevant order is order found in the input
message (ie, FIFO).  However, this order is not stable in the sense
required by the OP of this thread: existing fields may be deleted and
new ones inserted at arbitrary positions.  Nor does it refer to any
externally-defined collation order for fields.

BTW, I do understand the difference between sorting and ordering.
What I missed is that that Amir (the OP) didn't ask for his
BasicStruct to be Ordered (although I guess it would be, considered as
a container for its slots); he wants to check that the initializer for
__slots__ is Ordered.

But that is insufficient in this use case (an alphabetically-ordered
instance would be a problematic initializer: consider a derived
BasicStruct that adds members to its parent BasicStruct).  I still
question the general usefulness of this ABC on the one hand, and ask
how far to proliferate its more useful subclasses on the other.