Amaury Forgeot d'Arc <amaur...@gmail.com> added the comment: So the discussion is now on 2 points:
1. Is the change backwards compatible? (at the code level, after recompilation). My answer is yes, because all known case transformations stay in the same plane: if you pass a char in the BMP, they return a char in the BMP; if you pass a code >0x1000, you get another code >0x1000. In other words: in narrow builds, when you pass Py_UNICODE, the answer will be correct even when downcasted to Py_UNICODE. If you want, I can add checks to makeunicodedata.py to verify that future Unicode standards don't break this statement. "Naive" code that simply walks the Py_UNICODE* buffer will have identical behavior. (The current unicode methods are in this case. They should be fixed, later) 2. Is this change acceptable for 3.2? I'd say yes, because existing extension modules that use these functions will need to be recompiled; the functions names change, the modules won't load otherwise. There is no need to change the API number for this. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5127> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
