On Jan 27, 2008 3:37 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> The actual claim seems to have been that the semantics of int(<float>)
> itself is fuzzy. This in turn seems to be based one of two ideas (I am not
> sure which)
> a. 'int' might either mean to some people 'some int associated with the
> float input' rather than the more precise 'the integer part of the float
> input', or
Just like set(sequence) is the set associated with that sequence, not
the set part of that sequence, and float('3.14') is the float
associated with '3.14', not the float part of '3.14', etc. Type names
do not normally retrieve pieces of other objects. When there's no
unique or otherwise special instance of a given type associated with
an instance of another type, the first should not take the second in
its constructor. (This does not imply the inverse.)
On the other hand, to retrieve a piece of another object, you do
normally call a member on that object, so I'd have no objections to
changing trunc() and round() (although the second isn't strictly
retrieving a piece) to methods.
> b. that some people might think the latter means the same as the former.
I don't understand this sentence. I haven't seen anyone advocating
trunc() say that "some int associated with" means the same as "the
integer part of".
> Possibility a is easy taken care of by documentation, especially when the
> behavior is what people expect.
I'll grant that the behavior is relatively easily learned. It'll take
some more evidence to convince me that it's what people expect, given
that it _looks_ like a type conversion, and many systems implement
that conversion by rounding.
> Possibility b conflicts with what I
> believe to be both the plain English meaning of 'integer part' and what I
> believe Americans, at least, learn in elementary school.
You may understand the same thing from "int" and "integer part", but
that's a learned association that I didn't have before either you or
Raymond brought it up. Among their other differences, "int" is not an
English word.
> Moreover, I challenge the notion that 'truncate' is unambiguous. It simply
> means to cut off, without specifying how much. '3.141' is pi truncated to
> 3 decimal places. Indeed, it would not be unreasonable to expect trunc()
> to have a second parameter specifying where to cut.
No more unreasonable than round() having the same second parameter.
And it would be reasonable to default it to "0" as round() does, since
that's the only distinguished point in its range.
> For one data point, I asked my bright 13-year-old for the 'integer part' of
> 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()).
> But asking 'truncate' the same numbers or even 'truncate toward zero' got a
> blank stare, which did not surprise me too much as it is not a common
> (American) English word.
You asked a different question than the one we're talking about. You
should have asked your 13-year-old what the "int" of 3.9 was, or, even
better, how to convert 3.9 to an integer. For the first, you'd likely
have gotten the same blank stare. For the second, I expect you'd have
gotten either 4, or an objection that it's simply not an integer and
can't be "converted" to one.
--
Namasté,
Jeffrey Yasskin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
