[Python-Dev] Strings: '\012' -> '\n'
Guido van Rossum
Mon, 15 Jan 2001 23:13:40 -0500
> > So... i'm submitting a patch that causes the three most common
> > special whitespace characters, '\n', '\r', and '\t', to appear in
> > their natural form rather than as octal escapes when strings are
> > printed and repr()ed.
> -1 on doing that when they're printed (although I probably misunderstand
> what you mean there).
Ping was using imprecise language here -- he meant repr() and "printed
at the command line prompt."
> +1 for changing repr() as suggested.
> -0 on generalizing to \a \b \f \v too (I've never used one of those in a
> string literal in my life, so would be more baffled by seeing one come back
> than I would the octal equivalent).
> I would also be +1 on using hex escapes instead of octal (I grew up on 36-
> and 60-bit machines, but that was the last time octal looked *natural*!).
Me too. One summer vacation while in college I had nothing better to
do than decode the Pascal runtime system for the University's CDC-6600
from an octal dump into assembly. Learned lots!
> Octal and hex escapes both consume 4 characters, so I can't imagine what
> octal has going for it in the 21st century <wink>.
Originally, using \x for these was impractical (at least) because of
the stupid gobble-up-everything-that-looks-like-a-hex-digit semantics
of the \x escape. Now we've fixed this, I agree.
> 377-is-an-irritating-way-to-spell-ff-ly y'rs - tim
> PS: Note that C doesn't define what numerical values \a etc have, just
> Each of these escape sequences shall produce a unique
> implementation-defined value which can be stored in a single
> char object. The external representations in a text file need
> not be identical to the internal representations, and are
> outside the scope of this International Standard.
> The current method does have the advantage of extreme clarity.
Python doesn't support non-ASCII machines, like the C standard
--Guido van Rossum (home page: http://www.python.org/~guido/)