The test is still failing on "x86 FreeBSD 7.2 3.x" and "sparc solaris10 gcc
3.x" buildbots. It looks like the locale encoding is able to decode b'\xff'. I
suppose that it is an encoding like 'iso-8859-1'.
Use C locale to set, I hope, the locale encoding to 'ascii'. Display also the
encoding so if the test fails, at least I will learn the locale encoding
choosen for the C locale.
There are buildbot failures on "x86 FreeBSD 3.x" and "sparc solaris10 gcc 3.x".
I suppose that _Py_char2wchar() doesn't fail even if the locale encoding is
unable to decode the byte string, because _Py_char2wchar() has a special mode
for platform without mbrtowc() (ISO C99) function.
Let's check my theory by avoid error on the Python print() instruction.
Find another way to generate a SyntaxError in the tests.
Previously, these statements would raise something strange like
TypeError: "'int' object is not iterable"
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84214 | amaury.forgeotdarc | 2010-08-19 23:32:38 +0200 (jeu., 19 août 2010) | 3 lines
Add tests for r84209 (crashes in the Ast builder)
Also remove one tab, and move a check closer to the possible failure.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84209 | amaury.forgeotdarc | 2010-08-19 19:43:15 +0200 (jeu., 19 août 2010) | 5 lines
Check the return values for all functions returning an ast node.
Failure to do it may result in strange error messages or even crashes,
in admittedly convoluted cases that are normally syntax errors, like:
def f(*xx, __debug__): pass
........
Failure to do it may result in strange error messages or even crashes,
in admittedly convoluted cases that are normally syntax errors, like:
def f(*xx, __debug__): pass
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84172 | martin.v.loewis | 2010-08-18 18:12:23 +0200 (Mi, 18 Aug 2010) | 2 lines
Restore GIL in nis_cat in case of error.
........
error handler, or strict error handler on Windows.
* Rewrite os.fsencode() documentation
* Improve os.fsencode and os.fsdecode() tests using the new PYTHONFSENCODING
environment variable
Database (Py_UNICODE_TOLOWER, Py_UNICODE_ISDECIMAL, and others) now accept
and return characters from the full Unicode range (Py_UCS4).
The differences from Python code are few:
- unicodedata.numeric(), unicodedata.decimal() and unicodedata.digit()
now return the correct value for large code points
- repr() may consider more characters as printable.
* Use the current filesystem encoding instead of always using utf-8
* Enable the test on Mac OS X
* Use TESTFN_UNENCODABLE and TESTFN_UNICODE instead of arbitrary filenames
* To decode a filename, use strict error handler instead surrogateescape for
mbcs encoding (on Windows)
* Use TESTFN_UNENCODABLE (if available) for the directory name
Skip the test if no non-ascii filename can be created.
... to get the filename as a unicode object, instead of a byte string. Function
needed to support unencodable filenames. Deprecate PyModule_GetFilename() in
favor on the new function.
