> 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
