[Distutils] Are chained comparisons allowed in environment markers?

[Vinay Sajip]

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

That's OK by me, I'm not too hung up on having those checks.

> 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.  ;-) )

So IIUC, that just means that the variables we support in expressions are:

* python_version, python_full_version, extra as in the PEP already.
* os_name instead of os.name.
* sys_platform instead of sys.platform
* platform_version instead of platform.version
* platform_machine instead of platform.machine
* platform_python_implementation instead of platform.python_implementation

How about just python_implementation for the last one?

> 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.  ;-)

Why should chained comparisons be disallowed? If we assume that inequalities are allowed, then surely "'v1' <= some_var < 'v2'" is a reasonable short-hand for "'v1' <= some_var and some_var < 'v2'"?

> 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 would say that we shouldn't allow r'', u'' or b'' prefixes in the spec. Logically, the values are text, i.e. Unicode. Both stdlib json and simplejson support Unicode escapes (\uxxxx) in string literals and handle them as expected. I don't see why we need the prefixes, since we're reading this data from text files rather than source code.

> 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.  ;-) )

I'd like to know what practical problems there would be with supporting Unicode escapes. As I understand it, you can convert to Unicode on 2.x by just using s.decode('unicode_escape').

Regards,

Vinay