How do you feel about parenthesis? It's probably not that hard to prohibit chained comparisons. Do we need an abnf? What's wrong with eval? On Apr 27, 2013 1:42 PM, "PJ Eby" <pje@telecommunity.com> wrote:
On Sat, Apr 27, 2013 at 11:57 AM, Vinay Sajip <vinay_sajip@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. ;-) ) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig