homepage

>>> t.pencolor(u'red')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "<string>", line 1, in pencolor
 File "/usr/lib/python2.7/lib-tk/turtle.py", line 2166, in pencolor
 color = self._colorstr(args)
 File "/usr/lib/python2.7/lib-tk/turtle.py", line 2600, in _colorstr
 return self.screen._colorstr(args)
 File "/usr/lib/python2.7/lib-tk/turtle.py", line 1111, in _colorstr
 r, g, b = [round(255.0*x) for x in (r, g, b)]
TypeError: can't multiply sequence by non-int of type 'float'

This patch solves the problem by making turtle check for string against basestring insted of str.

The bug showed up in a script that used:
from __future__ import unicode_literals

Presumably this is not an issue in 3.x. Is this considered a bug fix (in which case the patch should almost certainly be applied - it looks perfectly safe), or a feature enhancement (in which case this should get closed wontfix)? Looks like low-hanging fruit.

The particular error message is an artifact of 'red' having 3 letters, so that r,g,b = 'red' 'works'. turtle.pencolor(u'blue') raises
turtle.TurtleGraphicsError: bad color arguments: blue.
In general, 'solves the problem' is a bit vague. In this case, it should mean 'make the exception go away and actually actually changes the pencolor', which the patch does. Chunk 2 patches ._colorstr. Once a unicode passes the revised test, the subsequent line
 if self._iscolorstring(color) or color == "":
works because a) ._iscolorstring calls into tk, which is unicode based, and b) in 2.x, the comparison u''=='' is True. To be applied, test/test_turtle.py would need to have one or more tests added.
Chunks 2, 3, and 4 should fix all color issues. Chunk 1 is about file names instead. Though not stated, the intent appears to be to fix all possible issues with unicode_literals, as should be done if any are. (I did verify that there are no other isinstance(x, str) checks.) In particular, chunk 1 needs a test. Does
 if data.lower().endswith(".gif") and isfile(data):
 data = TurtleScreen._image(data)
work when data is unicode? The unicode==str comparison works. Does os.path.isfile(unicode) work? The os.path doc does not specify 'path', but unicode seems to work. TurtleScreen._image returns
 return TK.PhotoImage(file=filename)
I have not found any doc on whether the file option on 2.7 widgets can be unicode or not.
I asked on pydev about the generic issue of a 2.7 param being documented as a 'string' and the __future__ import changing str to unicode in thread 'unicode_string future, str -> basestring, fix or feature'.

The pronouncement on pydev is that this is a bugfix because the input are meant to be text and not specifically binary.

But there is also substantial disagreement. I will not do anything yet.

New changeset 1be39dc4409a by Terry Jan Reedy in branch '2.7':
Issue #15618: Make turtle.py itself work when run from a module with
http://hg.python.org/cpython/rev/1be39dc4409a 

I tested by changing a few strings in the demo at the end of the file to unicode. Any problems with os.path.isfile or Tk are different issues. Thanks for the patch.