[Python-ideas] Deprecating repr() and the like

[Steven D'Aprano]

On 10/08/13 06:52, Tim Peters wrote:

> And don't forget the digit 1!  It looks too much like lowercase letter
> L.  It would be silly require constructs like 42 // 42 instead, so
> let's add a new builtin "one":

Heh heh :-)

I would like to point out that Apple's Hypertalk language defined constants one through (I think) twelve, so you could write code like this:

add one to count
get word four of line two of text
put it into field "Something"

which worked well given the audience it was aimed at. But that sort of verbosity it doesn't really suit Python, which aims to be executable pseudo-code rather than pseudo-English.

Do you know what else doesn't really suit Python? An over-reliance on Perl-like cryptic symbols. Of the three code snippets:

     repr(obj).rjust(10)

     "%10r" % obj

     "{!r:>10}".format(obj)

there is no doubt in my mind that the first is more Pythonic. The second is much terser (and also potentially buggy, if obj happens to be a tuple), while the third manages to combine the cryptic use of symbols from the second with the verbosity of the first, and so satisfies nobody :-)

Having the option to give up readability for terseness is a good and positive thing. But neither should be the only-one-way to do it. repr() and string methods are the obvious way to do it.

If symbols were more Pythonic, rather than named functions, we'd have kept backticks `obj` and removed repr(obj). But we didn't.

-1 on deprecating named functions like repr.

-100 on deprecating named functions for removal in Python 4000 when there isn't even a schedule for Python 4000 yet. There isn't even a schedule for coming up with a schedule. It is premature to be making concrete code changes with an aim to Python 4000 yet. There may not even be a Python 4000, and if there is, it may not break backwards compatibility.



-- 
Steven