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
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