[Distutils] Finishing PEP 345

["Martin v. Löwis"]

> Right, this is not good because the comma means "and" then "or"
> 
> I see two ways to fix this:
> 
> - introduce groups, and say the the comma is "or" inside a group:
> 
>     0.9, (>1.0, !=1.3.4, <2.0), 3.4   ==> 0.9 or (>1.0 and !=1.3.4 and
> <2.0) or 3.4

This I don't like. It may be the disjunctive normal form, but I doubt
users will understand it.

> - use an explicit separator word (and/or)

There is a third solution: don't support "or". The only example in
the PEP that assumes "or" (i.e. "2.5, 2.6") could be rewritten as
">=2.5,<2.7".

BTW: how is "==" specified? Is "2.5.4" == "2.5"? If not, would
"2.5, 2.6" really mean "either Python 2.5 or Python 2.6, but neither
2.5.1 nor 2.6.1"?

>> For the Copyright field, I'm not sure what the purpose of it is.
>> If it is what I think it is (listing attribution), it should probably
>> be specified as "multiple use".
> 
> I just noticed this field was added after PEP 314. I don't think we
> should keep it at all.
> I don't see a use case for this (README etc.. are enough for copyright matters)

+1.

> What I have suggested last week was to introduce a delimiter to start
> each new line so
> this field stays RFC 822 compatible and reST works if we want to read
> back the value:
> 
> Description: This module collects votes from beagles
>            | in order to determine their electoral wishes.
>            | Do *not* try to use this module with basset hounds;
>            | it makes them grumpy.
>            |
>            | example code :
>            |
>            |      >>> 2 + 1
>            |      3

That may be reasonable, but it's also slightly incompatible. I.e. you'll
need to specify what happens if the vertical bar is missing (OTOH, for
1.2, you could actually require it).

> A cleaner option of course, is to drop the RFC 822 format and to use a
> simpler format like json for example, since we have a reader/writer
> for that in the stdlib.

That is a weak argument: we have readers and writers for rfc822 in the
stdlib also, and that was one of the reasons why this format was
originally chosen

> But that a big change...

I think the RFC822 way would be to use a MIME encoding in the header
(either Q or B) to transmit spaces reliable. But I don't think we
want that.

>> For Platform, I fail to see the point of supporting both multiple
>> use, and comma-separated lists.
> 
> Right. This is PEP 314 though, so we will need a deprecation cycle.
> The simplest way to fix this is to use (multiple use) and deprecate
> comma-separated I guess.

Not really. In 1.2, you can specify anything you like. That's the
whole point of having a version number in the data.

Regards,
Martin