[Python-Dev] unicode_string future, str -> basestring, fix or feature
Serhiy Storchaka
storchaka at gmail.com
Mon Mar 3 08:41:04 CET 2014
More information about the Python-Dev mailing list
Mon Mar 3 08:41:04 CET 2014
- Previous message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Next message: [Python-Dev] [RELEASED] Python 3.3.5 release candidate 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
03.03.14 02:02, Terry Reedy написав(ла): > On 3/2/2014 4:23 PM, Serhiy Storchaka wrote: >> 02.03.14 22:01, Terry Reedy написав(ла): >>> Is this a programmer error for passing unicode instead of string, or a >>> library error for not accepting unicode? >>> Is changing 'isinstance(x, str)' in the library (with whatever other >>> changes are needed) a bugfix to be pushed or a prohibited API expansion? >> >> 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 believe that in all cases when valid values are ASCII-only strings (format specifiers for array, struct, memoryview, etc), we can accept both str and unicode. Especially when they are likely literals. But when valid value can be non-ASCII (e.g. file names), it is a different case, because it requires additional and may be totally different code.
- Previous message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Next message: [Python-Dev] [RELEASED] Python 3.3.5 release candidate 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list