Since 2.2 Python can be compiled without unicode support (built with --disable-unicode configure option). Unfortunately, testing suite depends on the io module, which in 2.7 depends on the _io module, which requires unicode support. So for now testing unicodeless Python is not possible. Some other modules are failed when built without unicode support too.

Proposed patch fixes the io module in unicodeless build and includes also minor fixes fixes of compilation errors for other modules (except sqlite) and changes to auxilary files needed to build Python and run tests.

Patches for other components will be provided in separate issues.

Note MvL's comment (msg161191 in Issue8767) about not fixing test cases for --disable-unicode here.  This seems like a tremendous amount of code churn for a problem that has likely been around for years and would affect very few.  How widely is --disable-unicode used anyway?  Why fix these tests now, especially in 2.7?

I don't know anyone building Python without Unicode. I would prefer to modify configure to raise an error, and drop #ifdef in the code.

I think the purpose of this option is similar to --without-doc-strings, this decreases the size of Python binary (-0.5 MB).

Most needed changes are pretty trivial and they are only small fraction of already existing code for supporting --disable-unicode.

Serhly, I admire you for all of the obvious effort you put into this but I can't help but think it is misplaced effort.  My original comment was made before you submitted all of the other patches.  As it stands, to proceed with this, there are now tens of thousands of lines of patches to be reviewed.  It will take a lot of effort on a lot of people's part to properly review them.  And even then, no matter how careful you were, there will be new bugs introduced by these patches.  If it takes that much change to properly support --disable-unicode, then it's clearly been a broken feature and fixing it now is on the scale of a large new feature for 2.7.  That just doesn't seem to me like a good choice based on the need for core developers' time and the added risk for the overwhelming majority of Python 2.7 users, who use Unicode-enabled builds.  I think we need to have a discussion on python-dev and a ruling by Benjamin.

Ned, I think you misunderstood Martin. He approved patch which fixes some 
disabled-unicode bugs. He noted that fixing a number of test failures has very 
low priority. This issue is about fixing the possibility of build Python and 
run test suite itself. And all other issues (except issue21834) fixes bugs in 
stdlib, not only in tests (issue21835 and issue21836 also fixes compile 
errors).

IMO supporting building Python 2 without Unicode support should be discussed on the python-dev mailing list, it's not an innocent change.

Python is moving strongly to Unicode: Python 3 uses Unicode by default. So to me it sounds really weird to work on building Python 2 without Unicode support. It means that you may have "Python 2" and "Python 2 without Unicode" which are not exactly the same language. IMO u"unicode" is part of the Python 2 language.

--disable-unicode is an old option added while Python 1.5 was very slowly moving to Unicode.

--

I have the same opinion on --without-thread option (we should stop supporting it, this option is useless). I worked in the embedded world, Python used for the UI of a TV set top box. Even if the hardware was slow and old, Python was compiled with threads and Unicode. Unicode was mandatory to handle correctly letters with diacritics.

The subsequent discussion didn't arrive at a consensus. Most commenters wanted to drop --disable-unicode support and thought these patches were too extensive for 2.7, but Serhiy noted that running the tests with --disable-unicode turns up problems in the Unicode enabled code.  There was no pronouncement from the BDFL or a release manager.

The python-dev discussion is archived at https://mail.python.org/pipermail/python-dev/2014-June/135181.html