Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <54ccc2fc$0$13009$c3e8da3$5496439d@news.astraweb.com>
References: <54c07d04$0$13012$c3e8da3$5496439d@news.astraweb.com> <1939680766443642112.878725sturla.molden-gmail.com@news.gmane.org> <CANc-5Uy3as3J=_h7oJiG4xY9kwSzchmxt=6bKZoEQhc4HHvePA@mail.gmail.com> <mailman.17982.1421951313.18130.python-list@python.org> <6eb91c4b-92ff-44a8-b5a9-6ef04c71f4cb@googlegroups.com> <MPG.2f2b9739d70d7220989688@nntp.aioe.org> <35a40ec6-3763-448b-9ea4-4a233a04979b@googlegroups.com> <54c1ccc8$0$13005$c3e8da3$5496439d@news.astraweb.com> <mailman.18150.1422284487.18130.python-list@python.org> <54c6d7c2$0$12992$c3e8da3$5496439d@news.astraweb.com> <mailman.18178.1422380228.18130.python-list@python.org> <MPG.2f31f0482d3837cb98969f@nntp.aioe.org> <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com> <MPG.2f3318cb4d02fd059896b2@nntp.aioe.org> <mab931$qqu$1@ger.gmane.org> <mailman.18262.1422540523.18130.python-list@python.org> <54ca583e$0$13005$c3e8da3$5496439d@news.astraweb.com> <mailman.18276.1422555831.18130.python-list@python.org> <54ccc2fc$0$13009$c3e8da3$5496439d@news.astraweb.com>
Date: Sun, 1 Feb 2015 01:53:17 +1100
Subject: Re: Python is DOOMED! Again!
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18340.1422716000.18130.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:84955

On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Both ints and floats are models of the same abstract thing, namely "number".
> Ideally, from a mathematically standpoint, there should be no difference
> between 23 and 23.0. Automatic coercions allow us to get a little closer to
> that ideal.

So far, I'm mostly with you. (Though if your float type is not a
perfect superset of your integer type - as in Python - then the
default "up-cast" from int to float, while disallowing a corresponding
implicit "down-cast", seems flawed. But in concept, yes, automatic
coercion allows us to treat 23 and 23.0 as the same.)

> Arbitrary objects, on the other hand, are rarely related to strings. Given
> that we need to be able to display arbitrary objects to the human
> programmer, if only for debugging, we need to be able to *explicitly*
> convert into a string:
>
>
> py> import nntplib
> py> SERVER = "news.gmane.org"
> py> server = nntplib.NNTP(SERVER)
> py> str(server)
> '<nntplib.NNTP instance at 0xb7bc76ec>'

Here, though, I'm not so sure. Why should you be able to *type-cast*
anything to string? Python has another, and perfectly serviceable,
function for converting arbitrary objects into strings, and that's
repr(). It would make perfect sense for a language to make this
distinction much more stark:

1) str() attempts to convert something into a string. It can do this
automatically in the case of "string-like" objects (eg buffers, maybe
some magical things that come from databases), and can convert others
with help (eg bytes->string using an encoding parameter), but anything
else will raise an error.

2) repr() guarantees to convert anything into a string. It does this
in a relatively arbitrary fashion; you can write a helper method for
your class to make this more useful to the human.

#2 is how Python's repr already functions, so explicitly converting
arbitrary objects into strings is covered. The idea that we can str()
them as well isn't necessarily part of a sane typing system.

(Note that I'm not saying that Python got it wrong, here; just that
taking the alternate choice would also be not-wrong.)

> but doing so *implicitly* gains us nothing except the saving of a few
> keystrokes, while risking serious bugs.

Complete and automatic casting to string, I would agree. However, I
would suggest that there are a few *binary operations* which could be
more convenient if they allowed some non-strings. For instance, Pike
allows addition of strings and integers: "1" + 2 == "12", where Python
requires "1" + str(2) for the same operation. (But Pike does *not*
allow just any object there. Only a few, like numbers, can be quietly
cast on being added to strings.)

> Forcing all arbitrary objects to
> support string operations would be pointless and confusing. What could this
> possibly mean?
>
> server.replace('7', 'FOO')

Well duh, you would go to the server and replace the 7th stored post
with the new body 'FOO' :)

Strings have *tons* of methods. There's no way you'd want them all on
every object, and it wouldn't make sense. You definitely don't up-cast
everything to string just to use methods on them... I can't imagine
any (sane) language ever doing that.

ChrisA