[Python-Dev] [Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c

[Tim Peters]

[Jeremy Hylton]
>> I think this solution is better.  It's relatively rare for people to
>> change the ast definition, so for most purposes these should be static
>> files.

[Martin v. Löwis]
> Interestingly enough, I found yesterday that Python-ast.c did change for
> me, even though I had not touched the AST grammar at all. Assuming
> somebody forgot to commit this file, I just did.
>
> I now investigated where this change originated from, and it was this
> commit
>
> r41812 | tim.peters | 2005-12-26 00:18:31 +0100 (Mo, 26 Dez 2005) | 2 lines
>
> Whitespace normalization.
>
> This indicates two problems: apparently, the whitespace normalization
> also normalizes string literals; not sure whether this is a good idea
> or not.

reindent.py never leaves a hard tab character behind, or a line with
trailing whitespace.  Those are features, because they're invisible,
and _someone's_ editor is going to destroy either or both of those
sooner or later anyway.  No core code should rely on them (inside
string literals or not).

I don't believe that asdl_c.py requires either hard tab characters or
trailing whitespace on lines (both of which reindent.py
replaced/removed), and reindent.py's output is a fixed-point for
reindent.py, so those shouldn't happen again (unless/until someone
sticks hard tabs or trailing whitespace into asdl_c.py again).

If someone is really keen to have hard tab characters inside the CODE
strings written by this file, then "the right" way to do that is to
use \t escapes inside the triple-quoted strings (instead of using
embedded hard tab characters).

> Furthermore, people should be made aware that something
> deserves their attention when they find that Python-ast.c has changed
> for them (but I guess Tim never saw Python-ast.c change, because this
> build step isn't executed on Windows).

I can do better than guess about that ;-)