New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure: Cannot disable unicode #53013
Comments
I am compiling python on AIX 5.3. The normal configure and make works, except it fails to compile the unicodedata module. The assembler reports a bunch of these errors: The module is labeled as optional, but if that one fails python will not install. One of the .py files it tries to compile requires unicodedata so the whole thing fails. I tried --enable-unicode=ucs4 and got the same results so then I tried just --disable-unicode all together and configure spits out: I had to go into the configure script itself remove a default case statement that produced the error to disable it completely. Building Python2.7b1 on AIX 5.3 |
Seems as though python 2.7 should not support --disable-unicode so this ticket is invalid. I just googled python disable unicode, but it seems that the decision to never disable unicode is recent. |
Reopening per this python-dev thread where MvL said that not being able to build 2.7 without unicode is a bug (but someone would need to care enough to contribute a patch to fix it). |
Here's the patch. It has four goals:
The one-line modification to configure.ac (and consequentley autoreconf'ed configure) achieve goal 1. The changes to the three C files (which are nothing more than a few #ifdef Py_USING_UNICODE) achieve goal 2: you can run "./python -S". The fix for site.py takes care of posixpath, glob, (and a few other modules) and makes it possible to compile most of the C extensions of the stdlib, goal 3 -- The compilation process under posix requires posixpath and glob to work. The most notable extension that won't be built is, unsurprisingly enough, io. Fortunately it does not play in Python 2.7 the central role it plays in Python 3. Still, a few other modules depend on it and won't be usable. The changes in Lib/test/script_helper.py and Lib/test/test_support.py make it possible to run the test suite. Roughly one third of the tests will fail, though, but I think that's acceptable. In relation to my purpose for submitting this patch ( bpo-1065986 ) , I note that test_pydoc runs and succeeds. |
I find the injection of a fake unicode class too hacky. Instead, I suggest that each module does try: and then have the isinstance checks look for _unicode |
Martin, That was exactly my first approach. What made me change my mind is that i) it is also fairly hacky (one might rightfully object that it is the isinstance(x, unicode) tests that should be changed) ii) it is now a hack spread over a dozen files, instead of the site.py alone. iii) the alterations in those files are executed even in the case of built-in unicode support, thus increasing the risk of introducing a regression in the stdlib. In the end I was a bit loath to alter quite a few of the stdlib modules (including some of the "core" ones) for a rather infrequent case. My solution, on the other hand, is such that in the regular case of built-in unicode support those modules are not touched at all, thus reducing the risk of introducing a regression in the stdlib. Still, if you guys do think that the maintainability risk due to the hackiness of my suggestion exceeds the potential benefits, it might be better to split the issue (and the patch) into two: one for the autoconf and interpreter, and one for the stdlib. In this way, the patch for autconf and interpreter (which should be less controversial) might be accepted sooner, while we bide our time until we come up with a better solution for the stdlib. |
Please do that. Splitting the patch could be enough, no need to split |
Here we go. |
New changeset d7aff4423172 by Martin v. Löwis in branch '2.7': |
Thanks for the patch. I did the library patch without monkey-patching. If there are further issues with this feature, please submit new bug reports. I won't consider the many test failures due to usage of Unicode literals in the test cases as bugs, as working around for the lack of Unicode literals is quite tedious, and would reduce readability. |
Understood and agreed. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: