> David Goodger wrote:
>> Should we leave a "set_class" method in place, for compatibility?
> Yes, why not. But I'd like to see it as "deprecated" (print a
> warning to STDERR, or just in the docstring?) because otherwise
> people won't change their code.
OK, deprecation warning it is. Done.
> This is necessary (IMO) because the class logic in Docutils has
> *really* changed (not just the interface). 3rd-party code that is
> using set_class *may* happen to work with the
> compatibility-set_class method, but it might be passing multiple
> classes in one string or it might check if the old 'class' attribute
> is set, which will both lead to subtle bugs.
I think you may be worrying too much. After all, we can't prevent
client code from doing "Element.attributes['classes'].append('text
with multiple space-sparated words')", can we? Even the "assert ' '
not in name" you added seems like overkill to me.
> Using the set_class method in current code (as in r3221) is just
> adding unnecessary redirection, IMO.
I removed set_class, only to put it back. It was probably there to
begin with because Chris wrote it to work with the released code,
version 0.3.7, instead of bleeding-edge SVN. This got me thinking
about the issue -- what API changes should we be making, and how?
Leaving obsolete methods behind for a while (how long?), but adding
deprecation warnings, seems like a good general policy. It's much
kinder to end-users than the alternative.
David Goodger <http://python.net/~goodger>