Bret Aarden <bret.aar...@gmail.com> writes:
>>> + def print_note_color (self, object, rgb=None):
>>> + if rgb:
>>> + str = ("\override %s #'color = #(rgb-color %s %s %s)" %
>>> + (object, rgb[0], rgb[1], rgb[2]))
>>>
>>
>> I suppose this should be \\override (i.e. escape the backslash).
>>
> Well, it's been a while since I've worked with Python in depth, but it
> seems to work fine without it.
It will probably work silently (or with warning?) until such a time that
some future Python version defines the escape \o to actually mean
something, and will then break.
That's not a good idea. The Python language definition says:
Unlike Standard C, all unrecognized escape sequences are left in the
string unchanged, i.e., the backslash is left in the string. (This
behavior is useful when debugging: if an escape sequence is
mistyped, the resulting output is more easily recognized as broken.)
It is also important to note that the escape sequences marked as
“(Unicode only)” in the table above fall into the category of
unrecognized escapes for non-Unicode string literals.
I consider this imprudent. At the very least, I don't think it a good
idea to rely on \o to make it through unmolested in all future versions
of Python.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
