It has no sense to check if a not ready string is ASCII or not.

If maxchar_new == 0 and self is a unicode subtype, return u instead of duplicating u.

_PyUnicode_CheckConsistency() also checks string content.

 * Remove micro-optimization from PyUnicode_FromStringAndSize():
   PyUnicode_DecodeUTF8Stateful() has already these optimizations (for size=0
   and one ascii char).
 * Rename utf8_max_char_size_and_char_count() to utf8_scanner(), and remove an
   useless variable

 * Create decode_utf8_errors()
 * Reuse unicode_fromascii()
 * decode_utf8_errors() doesn't refit at the beginning
 * Remove refit_partial_string(), use unicode_adjust_maxchar() instead

Issue #13248: turn 3.2's PendingDeprecationWarning into 3.3's DeprecationWarning (cgi, importlib, nntplib, smtpd).

Test the following functions:

 * codecs.raw_unicode_escape_decode()
 * PyUnicode_FromWideChar()
 * PyUnicode_FromUnicode()
 * "unicode_internal" and "unicode_escape" decoders

instead of UTF-8, if the wcsftime() function is not available.

UTF-8, if the wcsftime() function is not available.

Skip locales triggering the mbstowcs() bug. I collected the locale list thanks
my previous commit:

 * hu_HU (ISO8859-2): character U+30000020
 * de_AT (ISO8859-1): character U+30000076
 * cs_CZ (ISO8859-2): character U+30000020
 * sk_SK (ISO8859-2): character U+30000020
 * pl_PL (ISO8859-2): character U+30000020
 * fr_CA (ISO8859-1): character U+30000020

a mbstowcs() bug. For example, on Solaris, the hu_HU locale uses the locale
encoding ISO-8859-2, the thousauds separator is b'\xA0' and it is decoded as
U+30000020 (an invalid character) by mbstowcs().

The workaround is not enabled yet (commented): I would like first to get
more information about the failing locales.

bug. On Solaris, if the locale is hu_HU (and if the locale encoding is not
UTF-8), the thousauds separator is b'\xA0' which is decoded as U+30000020
instead of U+0020 by mbstowcs().