* Create copy_characters() function which doesn't check for the maximum
   character in release mode
 * _PyUnicode_CheckConsistency() is no more static to be able to use it
   in _PyUnicode_FormatAdvanced() (in formatter_unicode.c)
 * _PyUnicode_CheckConsistency() checks the string hash

would be finalized after the reference to its underlying BufferedRWPair's
writer got cleared by the GC.

root, since the semantics varies across Unix variants.

root (directory permissions are ignored).

Reported and diagnosed by Thomas Kluyver.

if the underlying raw stream is unseekable, even if the seek could be
satisfied using the internal buffer.  Patch by John O'Connor.

- bigmemtest is replaced by precisionbigmemtest
- add a poor man's watchdog thread to print memory consumption

metaclass is registered with copyreg.  Patch by Nicolas M. Thiéry and
Craig Citro.

ucs1, ucs2 and ucs4 libraries have to scan created substring to find the
maximum character, whereas it is not need to ASCII strings. Because ASCII
strings are common, it is useful to optimize ASCII.

would be finalized after the reference to its underlying BufferedRWPair's
writer got cleared by the GC.

Try to only create non ready strings in debug mode to ensure that all functions
(not only in unicodeobject.c, everywhere) make input strings ready.

Try to stop the scanner of the maximum character before the end using a limit
depending on the kind (e.g. 256 for PyUnicode_2BYTE_KIND).

If we have at least one character in U+10000-U+10FFFF, we know that we must use
PyUnicode_4BYTE_KIND kind.

 * str[a:b] doesn't scan the string for the maximum character if the string
   is ascii only
 * PyUnicode_FromKindAndData() stops if we are sure that we cannot use a
   shorter character type. For example, _PyUnicode_FromUCS1() stops if we
   have at least one character in range U+0080-U+00FF