> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4