[Python-Dev] Re: PendingDeprecationWarning

[Alex Martelli]

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'...!-)


Alex