Tweaked at http://hg.python.org/peps/rev/75474fb879d3
On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull
<step...@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:
_______________________________________________
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/archive%40mail-archive.com
