On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
<steve+comp.lang.pyt...@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
--
https://mail.python.org/mailman/listinfo/python-list
