25.06.14 00:03, Jim J. Jewett написав(ла): > It would be good to fix the tests (and actual library issues). > Unfortunately, some of the specifically proposed changes (such as > defining and using _unicode instead of unicode within python code) > look to me as though they would trigger problems in the normal build > (where the unicode object *does* exist, but would no longer be used). This is recomended by MvL [1] and widely used (19 times in source code) idiom. [1] http://bugs.python.org/issue8767#msg159473 > Other changes, such as the use of \x escapes, appear correct, but make > the tests harder to read -- and might end up removing a test for > correct unicode funtionality across different spellings. > > Even if we assume that the tests are fine, and I'm just an idiot who > misread them, the fact that there is any confusion means that these > particular changes may be tricky enough to be for a bad tradeoff for 2.7. > > It *might* work if you could make a more focused change. For example, > instead of leaving the 'unicode' name unbound, provide an object that > simply returns false for isinstance and raises a UnicodeError for any > other method call. Even *this* might be too aggressive to 2.7, but the > fact that it would only appear in the --disable-unicode builds, and > would make them more similar to the regular build are points in its > favor. No, existing code use different approach. "unicode" doesn't exist, while encode/decode methods exist but are useless. If my memory doesn't fail me, there is even special explanatory comment about this historical decision somewhere. This decision was made many years ago. > Before doing that, though, please document what the --disable-unicode > mode is actually *supposed* to do when interacting with byte-streams > that a standard defines as UTF-8. (For example, are the changes to > _xml_dumps and _xml_loads at > http://bugs.python.org/file35758/multiprocessing.patch > correct, or do those functions assume they get bytes as input, or > should the functions raise an exception any time they are called?) Looking more carefully, I see that there is a bug in unicode-enable build (wrong backporting from 3.x). In 2.x xmlrpclib.dumps produces already utf-8 encoded string, in 3.x xmlrpc.client.dumps produces unicode string. multiprocessing should fail with non-ascii str or unicode. Side benefit of my patches is that they expose existing errors in unicode-enable build.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4