[Python-Dev] Draft Guide for code migration and modernation

[Guido van Rossum]

> > Hm, but repr() was the wrong thing to call here anyway. :-(
> 
> The old code used `x`. Should we change it to use str()?

Can't do that, it's an incompatibility.  In a module of mostly
historic importance, it doesn't make sense to change it incompatibly.

> > Would it hurt to make them spaces in ASCII
> > too?
> 
> stringobject.c::string_isspace() currently uses the isspace()
> function from <ctype.h>.

I guess we'll have to live with this difference.  There's not much
harm, since nobody uses these anyway.

> grep "\[[[:space:]]*-[[:digit:]]*[[:space:]]*:[[:space:]]*\]" | grep "=="
> grep "\[[[:space:]]*:[[:space:]]*[[:digit:]]*[[:space:]]*\]" | grep "=="
> 
> This doesn't find "foobar"[-len("bar"):]=="bar", only constants.
> 
> But at least it's a little better than vgrep. ;)

Doesn't answer my question.  I'm doubting the wisdom of including
these grep instructions (correct or otherwise :-) for several reasons:

(1) It doesn't catch all cases (regexes aren't powerful enough to
    match arbitrary expressions)
(2) This recipe is Unix specific
(3) (Most important) it encourages "peephole changes"

By "peephole changes" I mean a very focused search-and-destroy looking
for a pattern and changing it, without looking at anything else.  This
can cause anachronistic code, where one line is modern style, and the
rest of a function uses outdated idioms.  IMO that looks worse than
all old style.  It can also cause bugs to slip in.  In my
recollection, every time someone went in and did a sweep over the
standard library looking for a particular pattern to fix, they
introduced at least one bug.

I much prefer such modernizations to be done only when you have a
reason to look at a particular module anyway, so you really understand
the code before you go in.

--Guido van Rossum (home page: http://www.python.org/~guido/)