Home Original page

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

Terry Reedy tjreedy at udel.edu
Sun Mar 2 21:40:31 CET 2014 
On 3/2/2014 3:12 PM, Guido van Rossum wrote:
> It looks to me like a defect in the library (*), and you are making a
> reasonable argument that we should fix it in 2.7 to help people be more
> prepared for the transition to Python 3.
>
> (*) As Antoine points out, pretty much the only time where it's not a
> good idea to switch from str to basestring is when the data is meant to
> be binary -- but in this case it's clearly text (we can also tell from
> what the same code looks like in Python 3 :-).

Thanks to both of you. 'bugfix' noted on the issue.
>
> On Sun, Mar 2, 2014 at 12:01 PM, Terry Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
>     Suppose a 2.7 standard library function is documented as taking a
>     'string' argument, such as these examples from the turtle module.
>
>     pencolor(colorstring)
>          Set pencolor to colorstring, which is a Tk color specification
>     string, such as "red", "yellow", or "#33cc8c".
>
>     turtle.shape(name=None)
>          Parameters: name – a string which is a valid shapename
>
>     class turtle.Shape(type_, data)
>          Parameters: type_ – one of the strings “polygon”, “image”,
>     “compound”
>
>     Suppose adding
>     from __future__ import unicode_literals
>     to a working program causes an exception, such as with turtle
>     http://bugs.python.org/__issue15618 <http://bugs.python.org/issue15618>
>     (Note: unicode_literals is not indexed.)
>
>     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?

-- 
Terry Jan Reedy
More information about the Python-Dev mailing list