[Python-Dev] unicode_string future, str -> basestring, fix or feature (original) (raw)
Stephen J. Turnbull stephen at xemacs.org
Mon Mar 3 03:26:46 CET 2014
- Previous message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Next message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Terry Reedy writes:
On 3/2/2014 4:23 PM, Serhiy Storchaka wrote:
Patches which add support for unicode strings were accepted for one issues (e.g. http://bugs.python.org/issue19099) and rejected for other issues (e.g. http://bugs.python.org/issue20014 and http://bugs.python.org/issue20015). Some issues (e.g. http://bugs.python.org/issue18695) hang in undefined state.
If Antoine and Guido don't reverse themselves, those could perhaps be re-opened. It strikes me as borderline, depending interpretation of 'string'. I am not surprised there have been different resolutions.
I agree with Victor in http://bugs.python.org/issue18695#msg208857: there's no "bug". It is just that in the design of 2.x 'str' is not Unicode, and the "fix" is Python 3. This may be an area where 2to3 could give more help.
As Victor points out in that message, the issue-by-issue approach to this inconsistency is just whack-a-mole.
I would worry not only about the whack-a-mole aspect where 'unicode' objects leak into contexts where they're not supported, but also that this could confuse tools like 2to3.
I agree that usage of the word "string" is all too often ambiguous in the documentation, but that doesn't justify a wholesale overhaul of the Python 2.7 API to make everything polymorphic.
- Previous message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Next message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]