PEP 426 comment: field order
I'd like to request that PEP 426 is extended to talk about the order of fields. In particular, for the Extension field, is it necessary that all "additional tags" follow immediately the respective Extension field? I also request that RFC 2119 terminology is followed strictly. In particular, the phrasing "Additional tags defined by the extension should be of the form string/Name:" is unclear - under what "particular circumstances" can I deviate from that requirement, i.e. use some form other than string/Name? Regards, Martin
Will add that the order is not significant. It is essentially a multidict.
On Thu, Oct 18, 2012 at 2:45 PM,
I'd like to request that PEP 426 is extended to talk about the order of fields. In particular, for the Extension field, is it necessary that all "additional tags" follow immediately the respective Extension field?
I also request that RFC 2119 terminology is followed strictly. In particular, the phrasing "Additional tags defined by the extension should be of the form string/Name:" is unclear - under what "particular circumstances" can I deviate from that requirement, i.e. use some form other than string/Name?
Regards, Martin
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
Added some notes about the (lack of) ordering. The email module provides an ordered multidict interface to the data. The first tag wins (if you improperly define Name: twice for example), but the order of everything is preserved. We just don't need it, except that it might be surprising to see your classifiers randomly re-ordered. It is also possible to textwrap.dedent(p['Description']) with p = email.parser.Parser().parsestr(metadata). I don't really expect anyone to use email.parser.Parser() so I'm hesitant to mention it, but it seems to work. I say it's read-only because the 3.2 Parser()/Generator() can't reserialize it due to Unicode. The improved Python 3.3 email module would be able to under the right conditions. diff -r 79e95f487a33 -r 4773b6b3e8f2 pep-0426.txt --- a/pep-0426.txt Thu Oct 18 08:31:44 2012 +0100 +++ b/pep-0426.txt Thu Oct 18 21:10:26 2012 -0400 @@ -33,10 +33,14 @@ The syntax defined in this PEP is for use with Python distribution metadata files. The file format is a simple UTF-8 encoded Key: value -format with no maximum line length. It is parsable by the ``email`` +format with no maximum line length. It is parseable by the ``email`` module with an appropriate ``email.policy.Policy()``. The field names listed in the `Fields`_ section are used as the header names. +In Python 3.2, a serviceable read-only parser is:: + + email.parser.Parser().parsestr(metadata) + There are two standard locations for these metadata files: * the ``PKG-INFO`` file included in the base directory of Python @@ -66,7 +70,8 @@ times in a single metadata file. Other fields may only occur once in a metadata file. Fields marked with "(optional)" are not required to appear in a valid metadata file; all other -fields must be present. +fields must be present. The fields may appear in any order within +the file. Metadata-Version :::::::::::::::: @@ -480,12 +485,17 @@ An ASCII string, not containing whitespace or the / character, that indicates the presence of extended metadata. Additional tags defined by -the extension should be of the form string/Name:: +an `Extension: Chili` should be of the form `Chili/Name`:: Extension: Chili Chili/Type: Poblano Chili/Heat: Mild +An implementation might iterate over all the declared `Extension:` +fields to invoke the processors for those extensions. As the order of +the fields is not used, the `Extension: Chili` field may appear before +or after its declared tags `Chili/Type:` etc. +
On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote:
The email module provides an ordered multidict interface to the data. The first tag wins (if you improperly define Name: twice for example), but the order of everything is preserved. We just don't need it, except that it might be surprising to see your classifiers randomly re-ordered.
Just to be clear, the email package preserves both the order and presence of headers. So if you do add Name: twice, both will be retained. Plenty of email headers (e.g. Received) can appear multiple times. The getitem API will indeed return just the first entry, but there is an alternative API that you can use to get all of them, in order. Deletions and re-insertions obviously change the order (the insertion is always an append), although there is a .replace_header() method for preserving existing order (kind of - only for the first instance of a header). Cheers, -Barry
On Fri, Oct 19, 2012 at 10:20 AM, Barry Warsaw
On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote:
The email module provides an ordered multidict interface to the data. The first tag wins (if you improperly define Name: twice for example), but the order of everything is preserved. We just don't need it, except that it might be surprising to see your classifiers randomly re-ordered.
Just to be clear, the email package preserves both the order and presence of headers. So if you do add Name: twice, both will be retained. Plenty of email headers (e.g. Received) can appear multiple times.
The getitem API will indeed return just the first entry, but there is an alternative API that you can use to get all of them, in order. Deletions and re-insertions obviously change the order (the insertion is always an append), although there is a .replace_header() method for preserving existing order (kind of - only for the first instance of a header).
It's a nice interface. I was surprised that there is no collections.OrderedMultiDict.
participants (3)
-
Barry Warsaw -
Daniel Holth -
martin＠v.loewis.de