C standard defines locale-specific *printing characters* that are [ -~]
in "C" locale for implementations that use 7-bit US ASCII character set
i.e., SP (space, 0x20) is a printing character in C (isprint() returns
nonzero).

There is isgraph() function that returns zero for the space but
otherwise is equivalent to isprint().

POSIX definition is aligned with the ISO C standard.

I don't know what RFC 5822 has to do with this issue but the rfc
contradicts itself e.g., in one place it has: "printable US-ASCII
characters except SP" that imlies that SP *is* printable but in other
places it considers isprint==isgraph. The authors probably meant
characters for which isgraph() is nonzero when they use "printable
US-ASCII" (that is incorrect according to C standard).

Tests from issue9770 show the relation between C character classes and
string constants [1]:

  set(string.printable) == set(C['graph']) + set(C['space'])

where C['space'] is '\t\n\v\f\r ' (the standard C whitespace).

It is a documented behavior [2]:

  This is a combination of digits, ascii_letters, punctuation,
  and whitespace

where *whitespace* is C['space'].

In Python 2, *printable* is locale-dependent and it coincides with the
corresponding Python 3 definition in "C" locale with ASCII charset.

Unlike other string constants, *printable* differs from C['print'] on
both Python 2 and 3 because it includes whitespace characters other than
space.

str.isprintable [3] obeys C['print'] (in ASCII range) and considers SP
to be printable.

---

It might be too late to change string.printable to correspond to C
isprint() (for ASCII characters).

I've uploaded a documentation patch that mentions that string.printable
and str.isprintable differ.

[1] http://bugs.python.org/review/9770/diff/12212/Lib/test/test_curses_ascii.py
[2] https://hg.python.org/cpython/file/3.4/Doc/library/string.rst#l62
[3] https://docs.python.org/3.4/library/stdtypes.html#str.isprintable