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
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