[Python-Dev] Re: PendingDeprecationWarning
Wed, 29 May 2002 22:13:48 +0200
On Wednesday 29 May 2002 09:42 pm, Guido van Rossum wrote:
> > Having both repr AND the peculiar `...` operator is another one of
> > those things which I find _really_ hard to explain without
> > handwaving and without sounding negative about Python, a language
> > about which I'm actually enthusiastic.
> Give yourself a bit of credit, Alex. Surely you can talk
> marketing-speak if you want to!
I'm pretty good at marketing _stricto sensu_, but not at obfuscation
(not deliberate one, I mean!-).
> > As to repr itself, I'd be +0 on taking it out of the builtins, but
> > that's hardly a major issue, nor of course a realistic prospect.
> Why get rid of repr()? It's very useful. In error messages I often
> want to show an object relevant to the message, but if that object is
> (or may be) a string, I don't want newlines and other control
> characters in the string to mess up the formatting of the error
> message. repr() is perfect for that.
Actually, in error messages I most often want to show objects
relevant to the message AND other strings or data too, so I
almost invariably end up using the % operator to format the
message string. Thus, I use the %r formatting specifier in the
format string, not a separate call to repr(), of course.
The 'representation' _functionality_ is indeed precious, although
often it's better supplied by MODULE repr (if I have a string in
error to show, I don't want to show an UNLIMITED amount of
characters from it -- module repr helps by limiting the amount
of data shown). I don't particularly care to have that very nice
functionality made available in three ways -- `...`, repr, and %r --
I'd rather have just one. But hey, I'll settle for two:-).
> How useful is formatting numbers with arbitrary bases? I think
Roughly as useful as _parsing_ numbers in arbitrary bases, as
offered by 2-arguments int() -- i.e., not very. It just DOES feel
a little weird to have it trivially easy to parse numbers in strange
bases but no corresponding ease in _output_.
> decimal and hex cover all current use cases; even octal is mostly
Almost all, yes. I've found myself using binary and (once) ternary,
but mostly in tricky ways rather than as plain I/O.
> historic. (I still read octal more quickly than hex, but that's
> showing my age more than anything else -- I grew up around a CDC
> mainframe that dumped in octal.)
We're roughly the same age, I think, and I grew up with DEC & HP
minis, CDC mainframes, and Intel and Zilog micros, which had _strong_
octal bias (reading 8080 machine-code dumps in octal was easy -- the
typical 1-byte commands had fields of 2-3-3 bits...). The difference is
that then I moved to IBM, where I was thoroughly indoctrinated in the
beauty of hex (try reading a _370_ machine-code dump in octal...!-).
Even IBM's main scripting language *rhymed* with 'hex'...!-)