Allowing Unicode literals even without Unicode support?
Many test modules fail because they use Unicode literals. It's easy enough to skip Unicode-related tests (just test for the existence of 'unicode'), but it's hard to avoid having Unicode literals in the text at all. Should we perhaps silently interpret Unicode literals as regular string literals when compiling without Unicode support? It's easy to do: *** compile.c 26 Apr 2002 01:57:19 -0000 2.242 --- compile.c 24 May 2002 18:21:29 -0000 *************** *** 1135,1147 **** #endif if (isalpha(quote) || quote == '_') { if (quote == 'u' || quote == 'U') { - #ifdef Py_USING_UNICODE quote = *++s; unicode = 1; - #else - com_error(com, PyExc_SyntaxError, - "Unicode literals not supported in this Python"); - return NULL; #endif } if (quote == 'r' || quote == 'R') { --- 1135,1143 ---- #endif if (isalpha(quote) || quote == '_') { if (quote == 'u' || quote == 'U') { quote = *++s; + #ifdef Py_USING_UNICODE unicode = 1; #endif } if (quote == 'r' || quote == 'R') { --Guido van Rossum (home page: http://www.python.org/~guido/)
GvR> Should we perhaps silently interpret Unicode literals as GvR> regular string literals when compiling without Unicode GvR> support?
+1, perhaps with a Warning?
-Barry
Adding the warning causes more code, while the only point of compiling without it is to have *less* code. Also, it would just cause tons of warnings when running the tests with Unicode disabled. --Guido van Rossum (home page: http://www.python.org/~guido/)
guido wrote:
Many test modules fail because they use Unicode literals. It's easy enough to skip Unicode-related tests (just test for the existence of 'unicode'), but it's hard to avoid having Unicode literals in the text at all.
I'm not sure having to write unicode("...") instead of u"..." qualifies as "hard", but life would be a bit easier if we didn't have to...
Should we perhaps silently interpret Unicode literals as regular string literals when compiling without Unicode support?
+1.0 on silently accepting ASCII-only u-literals also in non- unicode builds. -0.2 on silently accepting non-ASCII u-literals (your patch didn't deal with that, right?). </F>
I'm not sure having to write unicode("...") instead of u"..." qualifies as "hard", but life would be a bit easier if we didn't have to...
Life's hard enough without artificial discomfort.
Should we perhaps silently interpret Unicode literals as regular string literals when compiling without Unicode support?
+1.0 on silently accepting ASCII-only u-literals also in non- unicode builds.
-0.2 on silently accepting non-ASCII u-literals (your patch didn't deal with that, right?).
No, all I did was skip the 'u'. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Many test modules fail because they use Unicode literals. It's easy enough to skip Unicode-related tests (just test for the existence of 'unicode'), but it's hard to avoid having Unicode literals in the text at all. Should we perhaps silently interpret Unicode literals as regular string literals when compiling without Unicode support?
That would be like silently truncating floats to integers. It works as long as x == int(x), but doesn't for fractional values. -0 if you make sure that the literal is plain ASCII. -1 if you don't. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (4)
-
barry＠zope.com -
Fredrik Lundh -
Guido van Rossum -
M.-A. Lemburg