[Python-Dev] unicode_string future, str -> basestring, fix or feature (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Sun Mar 2 21:08:51 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 ]
On Sun, 02 Mar 2014 15:01:01 -0500 Terry Reedy <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 unicodeliterals to a working program causes an exception, such as with turtle http://bugs.python.org/issue15618 (Note: unicodeliterals is not indexed.) Is this a programmer error for passing unicode instead of string, or a library error for not accepting unicode?
In most cases I would say it's a library error. The only exception is when the argument is clearly meant as a byte string rather than a text string, such as when writing to a binary file or a socket.
Regards
Antoine.
- 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 ]