What I _mostly_ hope is that, if new gimmicks are adopted, they're enough
so that we never have to read a message about indentation again <0.3
grin>. This implies that anything too weak to permit using m4 in a
straightforward way to write Python macros will keep the issue on the
eternal-recurrence list. If it's going to be an eternally-recurring item
anyway, I'd just as soon leave it where it is so we can enjoy the
efficiency of reposting the same arguments via scripts <wink>.
> [marc]
> ... we should really have line numbers to find unintended line
> deletions.
Don't forget unintended insertions! But then there are intended
insertions, too, so the line numbers had better be floating-point. No,
that's no good, they need to be genuine reals, else we can't always find
a unique new line number between adjacent line numbers. I really want to
keep the line numbers monotonically increasing, else pymode will run like
a pig.
> Hmm, we could also require each line to be duplicated, thus finding yet
> more unwanted modifications.
A subtle advantage of my scheme is that the text of each line can be
encoded in its line number. Then we can do away with the text entirely.
_That_ should stop complaints about indentation! I propose instead that
a line number be indented a number of column spaces equal to the floor of
its natural logarithm. This way indentation will never decrease as you
go down the file, so a simple tool can detect many kinds of corruption,
and Guido can throw out all that messy DEDENT logic. It also has the
pleasant property that the indentation of no Python program can be made
to resemble a fractal, thus keeping undesirable elements out of this
group.
> Maybe add a MD5 signature for each source file, to detect bad data in
> the file system? <grin>
"Grin"? I never know when you folks are joking!
sounded-like-a-good-start-to-me-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp