String handling bug in Python

jepler at unpythonic.net jepler at unpythonic.net
Tue Apr 23 23:06:27 EDT 2002


On Wed, Apr 24, 2002 at 12:57:02PM +1200, Colin Brown wrote:
> Thanks guys
> 
> I did not think to look up this  "documented feature", sorry.

Well, how else would you suggest that "raw" strings should work?  For
instance, if you want to let
    r'\' == '\\'
how will you write the raw string that equals "\\'"?

You can't write r'\'' under your system because that's the raw string r'\'
(your system) followed by another (unmatched) '.

I suspect it turns out that no matter what scheme you decided on, there
are a few strings you can't express raw-ly.  I suspect that "no odd number
of trailing backslashes" is the best that can be done.  As far as I can
tell, your proposed scheme would forbid "apostrophe following an odd number
of backslashes" which excludes a greater fraction of strings from be
written raw-ly than the one Python actually employed.

The shortest way to write an almost-raw string with an odd number of
trailing backslashes is probably
    r'.......' "\\"
due to the builtin string concatenation that the parser performs.

> It still looks like a cop-out to me and can join my "ugly list" along with
> leading-zero octal numbers.

This is a feature inherited from C, as you probably know.  I noticed the
other day to my surprise that int("0377") != 0377, though (1.5.2 through
2.3a0).  I'll have to admit that I had non-computer-savvy colleagues
run into this one though, when I worked in the USGS back in '96 or so.
("How come this script doesn't work when I search for month >= 09 in
the file?")  I've also run into it when tcl is used as a scripting
language, especially when the "normal" (not base-10) number parsing
machinery was used on the string contents of entry widgets.  This may
well bite us again as we make our next-generation software scriptable
in Python... (Of course, I'll be excited when we can tell the engineers
that the expression '8+3/4' will actually give them 8 3/4 inches and
not 8 inches .. this despite my personal misgivings about future_division)

Jeff





More information about the Python-list mailing list