I need an idea for practise!

Chris Angelico rosuav at gmail.com
Fri Jul 18 05:23:50 CEST 2014

On Fri, Jul 18, 2014 at 1:07 PM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> For me, only the following targets need colorizing:
>       Keywords
>       Built-ins

And be sure *not* to colorize built-ins (but *do* colorize keywords)
in contexts where the tokens are actually identifiers, like "x.open =
1". Plus, if you want this to be truly general, you need to have it
understand that some keywords aren't keywords if the shebang is
different, although with 2.7 vs 3.4 that only really applies to
nonlocal (if True/False/None are colored as keywords even though
they're technically builtins, that's not a big deal); if you want to
support Python 2.5, you'd also have to cope with a __future__
directive adding a keyword, but that's quite optional.

It's not as simple as you might think. I've worked with plenty of
syntax highlighters that get something wrong in some context, and it's
extremely annoying; in some cases it makes the colorization actually
harmful, rather than helpful. And it's absolutely *essential* that the
lexer and the language agree on, for instance, what characters
constitute identifiers; if I have a partially non-ASCII variable name
and only the ASCII half of it gets highlighted, that can be highly


More information about the Python-list mailing list