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" <[email protected]> wrote: > On Sat, Apr 27, 2013 at 11:57 AM, Vinay Sajip <[email protected]> > 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 - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
