[Python-Dev] accept the wheel PEPs 425, 426, 427 (original) (raw)

Daniel Holth dholth at gmail.com
Sat Oct 20 02:07:14 CEST 2012

Tweaked at http://hg.python.org/peps/rev/75474fb879d3

On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

Executive summary:

You probably should include a full ABNF grammar....

The legacy PKG-INFO does not have email parse-ability. How about an example parser implementation instead, and drop email.parser.Parser() support. It will require a decent amount of additional editing.

This isn't RFC 822 unfolding at all. An RFC 822 "reader" will simply remove the CRLF and optionally "canonicalize" the spaces (the latter is not allowed by RFC 822, but sometimes it's observed). This implies that if you use an RFC 822 reader, you need to replace instances of the regexp r"\s+|" with a newline. (If you have a conforming reader, you can use the regexp r"\s{7}|" instead.) And of course you have to RFC-2047-encode non-ASCII in an RFC-822 field.

There is less RFC822 in the document now.

I can see that compatibility with email.parser.Parser() must have been a goal of the previous Metadata 1.2 spec. That is why it does the 7-spaces-plus-| trick. Otherwise two newlines would end the parsing (or the rest of the document would be the message body).

The email parser is significantly more permissive than the RFC.

Author-email now mentions RFC 5322.

> License (optional) > :::::::::::::::::: > > Text indicating the license covering the distribution where the license > is not a selection from the "License" Trove classifiers. See > "Classifier" below. This field may also be used to specify a > particular version of a licencse which is named via the Classifier A typo----------------------------+

> field, or to indicate a variation or exception to such a license. This won't do as is. It doesn't exclude the possibility of including a complete license, and if that is intentional, this field needs to be in the same format as "Distribution". Licenses are complex documents, needing at least some of the power of something like ReST. You may as well give them all of it.

Typo fixed. The ability to put the full license in a separate file exists, but would be part of the .dist-info spec. These files are parsed at runtime and it's obnoxious to have long descriptions and licenses in there.

> Project-URL (multiple-use) > Provides-Extra (multiple use)

Hyphen or no hyphen? Consistency is good.

No hyphen.

Switched to using must as in RFC MUST for extension fields ExtensionName/TagName:

More information about the Python-Dev mailing list