[Distutils] Are chained comparisons allowed in environment markers?

[PJ Eby]

On Sat, Apr 27, 2013 at 11:57 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Daniel Holth <dholth <at> gmail.com> writes:
>
>> Surely getting farther away from python by trying to prohibit useless
>> makers just makes the implementation needlessly complex.
>
> I'm not quite sure what you mean by "useless" markers. For example, distlib
> checks for e.g. "'2' == '2'" and e.g. "'os.name' == 'os.name'" as these are
> pointless to include in an environment marker, but that's only on the basis
> that (probable) errors shouldn't pass silently.

My test suite actually contains checks like that in order to verify
and/or logic, i.e., a bunch of "'x'=='x' and 'x'=='y'" type stuff, to
ensure that operator precedence is handled correctly, so I wouldn't
want to prohibit those in the spec.

I'm definitely in favor of switching to '_'; it'd let me delete some
lines from my implementation as well as making things clearer, and on
top of that it restores compatibility with the PEP 390 marker syntax.
(For whatever good that is, given that it's apparently being rejected
soon.  ;-) )

Anyway, I propose keeping the current spec but explicitly
*prohibiting* chained comparisons and concatenated string constants
(e.g. 'os.name=="win" "32"', which is valid Python 2 code.)  I would
also happily prohibit the use of '\' in strings, as that would let me
get rid of an eval in my implementation.  ;-)

Hm.  Actually i can get rid of that eval already if I use an
appropriate codec to decode the string...  but that brings up another
important question: are environment markers Unicode on Python 2?  Do
we need to support any non-ASCII characters in any of the provided
variables?  What happens if someone uses an r'', u'', or b'' string
constant?

I think we need to be a bit pickier about what subset of Python we're
supporting, so that we don't end up with implementation-defined
behavior.  Ideally, this would include dumbing strings down to ASCII
without backslashes or prefix characters.  If in the future a
non-ASCII usecase occurs for these strings, we could loosen the spec
then. (Hopefully after setuptools is out of the picture, since it's
still stuck using 8-bit files with unspecified encodings.  ;-) )