A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2014-March/132895.html below:

[Python-Dev] unicode_string future, str -> basestring, fix or feature

[Python-Dev] unicode_string future, str -> basestring, fix or featureSerhiy Storchaka storchaka at gmail.com
Mon Mar 3 08:41:04 CET 2014
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.


More information about the Python-Dev mailing list

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