On May 19, 2014, at 7:15 PM, Nick Coghlan <[email protected]> wrote:
> > On 19 May 2014 23:44, "Donald Stufft" <[email protected]> wrote: > > > > Currently PEP440 has a version specifier syntax like > > ``foo (2,~=2,==2,!=2,>=2,<=2,>2,<2)``. This is a hold over from PEP 345 of > > which I cannot locate a rationale for this change. > > It's at least in part to reduce ambiguity when listing multiple dependencies > as a list, rather than as line separated: > > foo(~=2,!=2.3.x), bar(~=3,!=3.5.4.x) > > That's why my initial reaction to the various aspects of the proposal was: > > +1 to dropping the default comparison operator now we have "~=" as an > explicit spelling > +1 for dropping the space between the package name and the opening > parenthesis (to be honest, I thought it was already at least optional , but > the PEP may not make that clear) > +0 for making the parentheses optional when only using a single comparison > operator > -0.5 for making the parentheses optional when using multiple comparison > operators > > On reflection, however, I'm switching back to "-1" for the latter two points. > That's a UI issue for user facing formats that has no place in the data > interchange specification. By contrast, the space is entirely redundant given > the parentheses, so it makes sense to me to drop it from the interchange > format. Allowing users to optionally include whitespace in version specifiers > then joins the ability to omit the parentheses as a tooling UI decision that > doesn't apply to the interchange standards. > > Remember, the metadata PEPs are about specifying the *normalised* forms that > are exchanged between automated tools. User facing tools are free to be more > liberal in what they accept and handle the normalisation on their users' > behalf > > Are we planning on putting these someplace where we can't unambiguously parse them? AFAIK in both the key:value form and the JSON form of the metadata are perfectly capable (and it is in fact no different processing wise) of handling them. AFAICT we're never going to rely on adhoc parsing here, at least we shouldn't, so we don't need any help from the specifier in discerning between two different ones. Even if this is for the interchange format there is value in having it consistent both for the benefit of the humans reading the interchange format and for the benefit of the tooling so that they don't have to maintain two different code paths to parse these. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
