[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding note color handling to musicxml2ly

From: David Kastrup
Subject: Re: Adding note color handling to musicxml2ly
Date: Wed, 15 Jul 2009 09:44:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Bret Aarden <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]