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.

Also remove one tab, and move a check closer to the possible failure.

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

Catch BytesWarning exceptions.

 * Check fs encoding value on Windows
 * Ignore LANG= test on Windows and Mac OS X (fs encoding is hardcoded on these
   platforms)

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

filesystem encoding is not related to sys.sizeof()

(Also fix a name ordering in the ACKS file.)

(the other functions where not affected by the recent change)

filesystem encoding.

initfsencoding() displays also a better error message if get_codeset() failed.

Matthew Ahrens.

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.

It is not sure it will be beneficial, though, since process launching is
more expensive under Windows than it is under Linux.

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