[Python-Dev] unicode_string future, str -> basestring, fix or feature (original) (raw)
Terry Reedy tjreedy at udel.edu
Sun Mar 2 21:01:01 CET 2014
- Previous message: [Python-Dev] "Five reviews to get yours reviewed"?
- Next message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 (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
- Previous message: [Python-Dev] "Five reviews to get yours reviewed"?
- Next message: [Python-Dev] unicode_string future, str -> basestring, fix or feature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]