Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
On Tue, Jun 24, 2014 at 6:15 PM, Nick Coghlan ncogh...@gmail.com wrote: Aye, in this case, I'm in the officially deprecate the feature camp. Definitely preferable to the suggestion to remove the configure flag. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
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. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
24.06.14 22:54, Ned Deily написав(ла): Benefit: - Fixes documented feature that may be of benefit to users of Python in applications with very limited memory available, although there aren't any open issues from users requesting this (AFAIK). No benefit to the overwhelming majority of Python users, who only use Unicode-enabled builds. Other benefit: patches exposed several bugs in code (mainly errors in backporting from 3.x). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
2014-06-25 14:58 GMT+02:00 Serhiy Storchaka storch...@gmail.com: 24.06.14 22:54, Ned Deily написав(ла): Benefit: - Fixes documented feature that may be of benefit to users of Python in applications with very limited memory available, although there aren't any open issues from users requesting this (AFAIK). No benefit to the overwhelming majority of Python users, who only use Unicode-enabled builds. Other benefit: patches exposed several bugs in code (mainly errors in backporting from 3.x). Oh, interesting. Do you have examples of such bugs? Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
25.06.14 16:29, Victor Stinner написав(ла):
2014-06-25 14:58 GMT+02:00 Serhiy Storchaka storch...@gmail.com:
Other benefit: patches exposed several bugs in code (mainly errors in
backporting from 3.x).
Oh, interesting. Do you have examples of such bugs?
In posixpath branches for unicode and str should be reversed.
In multiprocessing .encode('utf-8') is applied on utf-8 encoded str
(this is unicode string in Python 3). And there is similar error in at
least one other place. Tests for bytearray actually test bytes, not
bytearray. That is what I remember.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.3): Closes #20872: dbm/gdbm/ndbm close methods are not documented
In article 3gz1lk1lykz7...@mail.python.org, jesus.cea python-check...@python.org wrote: http://hg.python.org/cpython/rev/cf156cfb12e7 changeset: 91398:cf156cfb12e7 branch: 3.3 parent: 91384:92d691c3ca00 user:Jesus Cea j...@jcea.es date:Wed Jun 25 13:05:31 2014 +0200 summary: Closes #20872: dbm/gdbm/ndbm close methods are not documented The 3.3 branch is open only to security fixes. Please don't backport other patches to there. https://docs.python.org/devguide/devcycle.html#summary -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.3): Closes #20872: dbm/gdbm/ndbm close methods are not documented
On 25/06/14 20:35, Ned Deily wrote: The 3.3 branch is open only to security fixes. Please don't backport other patches to there. https://docs.python.org/devguide/devcycle.html#summary Ned, I am aware. It is a doc-only fix, like fixing a typo or correcting an incorrect statement. It that is against policy, let me know. That said, looks like 3.3 documentation is not sphinxed anymore to the webpage, so that actually makes the point high and clear. I have a browser tab open to check a 3.3 doc fix and it is not showing. Thanks for the heads up. Sorry for the inconvenience. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
On 26 Jun 2014 01:13, Serhiy Storchaka storch...@gmail.com wrote:
25.06.14 16:29, Victor Stinner написав(ла):
2014-06-25 14:58 GMT+02:00 Serhiy Storchaka storch...@gmail.com:
Other benefit: patches exposed several bugs in code (mainly errors in
backporting from 3.x).
Oh, interesting. Do you have examples of such bugs?
In posixpath branches for unicode and str should be reversed.
In multiprocessing .encode('utf-8') is applied on utf-8 encoded str (this
is unicode string in Python 3). And there is similar error in at least one
other place. Tests for bytearray actually test bytes, not bytearray. That
is what I remember.
OK, *that* sounds like an excellent reason to keep the Unicode disabled
builds functional, and make sure they stay that way with a buildbot: to
help make sure we're not accidentally running afoul of the implicit
interoperability between str and unicode when backporting fixes from Python
3.
Helping to ensure correct handling of str values makes this capability
something of benefit to *all* Python 2 users, not just those that turn off
the Unicode support. It also makes it a potentially useful testing tool
when assessing str/unicode handling in general.
Regards,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
