[Distutils] Are chained comparisons allowed in environment markers?

[PJ Eby]

On Sat, Apr 27, 2013 at 6:38 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> I was not proposing that we support inequalities.  They aren't so
>
>> problematic in themselves, as they are inviting various questions and
>> issues such as why they don't do any sort of version parsing.
>
> I'm not sure that platform_version inequalities make sense to support, because the semantics across different platform versions aren't clear cut, even on a given platform. But as far as python_version is concerned, there is an understanding about compatibility and Python X.Y versions. It doesn't seem like we need to do version parsing for python_version in the same way as we do for packages on PyPI.

So, can we keep inequalities (and therefore chained comparisons) out
of the spec then?  ;-)


>> My preferred way to deal with the whole thing is to allow single or
>> triple-quoted strings, disallow backslashes, and assume ASCII-only.
>
> Why do we need triple-quoted strings in environment markers?

We don't necessarily; I suggested allowing them only because if you
don't have backslashes and you need two kinds of quotes you'd
otherwise be out of luck.  But we could totally drop those, too.



>> That lets me avoid eval *and* string decoding on 2.x.  (My
>> implementation is actually single-source for 2.3 up through 3.2 at
>> least, but does so by assuming all the strings it handles are the same
>> type.)
>
> I thought you wouldn't need eval if you could use e.g. s.decode('unicode_escape') - are there problems with doing this in older Python versions?

It makes a single-source version of the code tougher, because strings
don't have a decode() method in Python 3.


> Also, given that setuptools and distribute are merging,  I presume that means that there will need to be some more flexibility in dealing with Unicode in 2.x code. I'm also hoping that some use can be made of my distribute3 fork, which runs on 2.x and 3.x without alteration or need for 2to3, and so has to deal with both bytes and Unicode.

I definitely want to move to a single source strategy ASAP, but that's
precisely why I'd prefer not to decode something that's already a
string of version-appropriate type.  ;-)

Mainly, I just want to keep the code size small, without opening too
many interop problems or backward compatibility issues.  If we outlaw
absolutely everything in the first version of the spec (and enforce
it), we don't end up with implementation-defined behavior, but can
still loosen restrictions later if an actual use case appears.