[Distutils] Finishing PEP 345

[Tarek Ziadé]

2009/12/23 "Martin v. Löwis" <martin at v.loewis.de>:
[..]
> 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".

Sure, that's even simpler,

>
> 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"?

Yes, 2.5 concerns all 2.5.x versions, but a micro version could be given as well
I am changing this

[..]
>> 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).

Yes, I was thinking about leaving 1.0 and 1.1 as they are, and add
this vertical bar in 1.2.
after the 8 spaces chars that are added after the EOLs.

>> 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

Let me rephrase it: RFC 822 was used because there were no reST fields
back then when PEP 314 was introduced.

RFC 822 doesn't fit well with what we need today (reST content) because
we have to encode the values in something that can be put in a header.

Using another encoding that knows how to encode/decode python structure
without having to take care of EOLs, space stripping, etc is just more
straightforward.
And we happen to have a json encoder/decoder in the stdlib.

But I am fine with the "|" solution with RFC 822.

Regards,
Tarek