<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
<div class="moz-cite-prefix">On 04/03/2013 09:04 AM, Steven
D'Aprano wrote:<br>
</div>
<blockquote cite="mid:515C52FB.2070705@pearwood.info" type="cite">On
04/04/13 01:16, Barry Warsaw wrote: <br>
<blockquote type="cite">It's analogous to all
<br>
the other built-in types-as-functions, so int() calls
__int__() which must
<br>
return a concrete integer.
<br>
</blockquote>
<br>
Why must it? I think that's the claim which must be justified,
not just taken <br>
as a given.
</blockquote>
<br>
</div>
Principle Of Least Surprise. My observation of the thread is that
the majority of people feel "of course __int__ needs to return a
real int". People are surprised that you can return subclasses.
Nick thought there was an explicit check to prevent it!<br>
<br>
Why is this so surprising? I think it's because int, str, and float
are all classes. Therefore, as callables they are constructors.
When you call a constructor, you expect to get an instance of that
specific class. Yes, it's always been possible with new-style
classes to return a subclass from the constructor. But calling a
constructor and getting a subclass is always surprising behavior.<br>
<br>
<br>
Also, permitting subclasses means the interface becomes conceptually
far more complicated. We would need to restrict it to subclasses
that don't hijack the representation. It's plausible, for example,
to write a subclass of str that uses a novel approach for storing
the string data, say as a rope. It could overload all the magic
methods and behave identically to a str in every important way. But
if its __str__ returned self instead of a real str object, that
means that PyUnicode_AS_UNICODE would blissfully return the bypassed
internal string value, whatever it is, and Python breaks. So we
can't enforce it programmatically, we'd need to document it as
convention. But explaining that is complicated, and If The
Implementation Is Hard To Explain, It's A Bad Idea.<br>
<br>
<br>
<blockquote cite="mid:515C52FB.2070705@pearwood.info" type="cite">
When we call n = int(something), what's the use-case for caring
that n is an
<br>
instance of built-in int but not of a subclass, and is that
use-case so
<br>
compelling that it must be enforced for all uses of int() etc.?</blockquote>
<br>
I'm much more interested in your counter use-case. When is it
appealing or necessary to you to return a subclass of int from
__int__()? In your postings so far you've said that this makes
sense to you, but you haven't said why you need it.<br>
<br>
In lieu of a compelling use case, my vote is firmly against surprise
and complexity.<br>
<br>
<br>
<i>/arry</i><br>
</body>
</html>