Tweaked at http://hg.python.org/peps/rev/75474fb879d3
On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull <[email protected]> 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: _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com