On Mon, Jan 28, 2008 at 08:07:21PM -0800, Guido van Rossum wrote:
PS. There's something wrong with Raymond's mailer that creates a
thread in gmail whenever he responds. I suspect it's not correctly
adding an In-reply-to header. That makes the thread feel much more
disconnected than most,
Jon Ribbens wrote:
On Mon, Jan 28, 2008 at 08:07:21PM -0800, Guido van Rossum wrote:
PS. There's something wrong with Raymond's mailer that creates a
thread in gmail whenever he responds. I suspect it's not correctly
adding an In-reply-to header. That makes the thread feel much more
Jeffrey Yasskin wrote:
[...]
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.
On Jan 25, 2008 11:21 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
... int() for making ints from the non-fractional
portion of a float.
To me, the concept of the integer part of a float isn't all that
well defined. It's really a property of a particular representation
rather than the
On 2008-01-27 08:14, Raymond Hettinger wrote:
. You may disagree, but that doesn't make it nuts.
Too many thoughts compressed into one adjective ;-)
Deprecating int(float)--int may not be nuts, but it is disruptive.
Having both trunc() and int() in Py2.6 may not be nuts, but it is
In article
[EMAIL PROTECTED],
Paul Moore [EMAIL PROTECTED] wrote:
On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
int has to be a builtin because it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it
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
On Jan 28, 2008 8:00 PM, Steve Holden [EMAIL PROTECTED] wrote:
I wish this thread could be truncated. It's got me going round and
round. I'm completely floored, and will doubtless end up barking mad -
you know, like a ceil.
Me too. All the arguments have been repeated over and over. It really
Raymond Hettinger wrote:
[Terry Reedy]
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
On Jan 26, 2008 11:14 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
The idea that programmers are confused by int(3.7)--3 may not be nuts, but
it doesn't match any experience I've had with any
programmer, ever.
In C, I'm pretty sure I've seen people write (long)x where they'd have
been
Raymond Hettinger wrote:
The idea that programmers are confused by int(3.7)--3 may not be nuts, but
it doesn't match any experience I've had with any
programmer, ever.
You haven't been doing newbie support in #python lately. Statements like
Python is rounding wrong are common. ;) It's
On Jan 26, 2008 11:14 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
. You may disagree, but that doesn't make it nuts.
Too many thoughts compressed into one adjective ;-)
[snip]
I don't think that Excel should be held up as a shining example for
Python.
It is simply a datapoint.
[snip]
On Jan 27, 2008 5:43 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
- Deprecating int(float) is pretty radical, I think it would have to
happen in the distant future. OR not at all. I'm at best +0 on this,
more like exactly 0. I realize that in practice this kills the idea.
The purist argument
On Jan 27, 2008 9:26 AM, Andrea Griffini [EMAIL PROTECTED] wrote:
On Jan 27, 2008 5:43 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
- Deprecating int(float) is pretty radical, I think it would have to
happen in the distant future. OR not at all. I'm at best +0 on this,
more like exactly
[Raymond Hettinger]
The idea that programmers are confused by int(3.7)--3 may not be nuts, but
it doesn't match any experience I've had with any
programmer, ever.
[Christian Heimes]
You haven't been doing newbie support in #python lately. Statements like
Python is rounding wrong are
[Guido]
There is actually quite an important signal to the reader that is
present when you see trunc(x) but absent when you see int(x): with
trunc(x), the implication is that x is a (Real) number. With int(x),
you can make no such assumption -- x could be a string, or it could be
a totally
On Jan 27, 2008 9:26 AM, Andrea Griffini [EMAIL PROTECTED] wrote:
On Jan 27, 2008 5:43 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
- Deprecating int(float) is pretty radical, I think it would have to
happen in the distant future. OR not at all. I'm at best +0 on this,
more like exactly
Is this a valid summary of the arguments so far?
I see two arguments for the change:
1) The semantics of trunc() are clear: it maps R - Z in a specific fashion
2) The semantics of int() are fuzzy; even non-numeric types
(strings) are handled
Yet there will be a __trunc__ that will allow any
On Jan 27, 2008 10:29 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Guido]
There is actually quite an important signal to the reader that is
present when you see trunc(x) but absent when you see int(x): with
trunc(x), the implication is that x is a (Real) number. With int(x),
you can
Then int(float) can be defined by deferring to trunc()
-- as opposed to round().
That part is new and represents some progress. If I understand it
correctly, it means that we won't have both __int__ and __trunc__
magic methods. That's a good thing.
Raymond
On Jan 27, 2008 10:39 AM, Michael Urman [EMAIL PROTECTED] wrote:
Is this a valid summary of the arguments so far?
I see two arguments for the change:
1) The semantics of trunc() are clear: it maps R - Z in a specific fashion
2) The semantics of int() are fuzzy; even non-numeric types
On Jan 27, 2008 10:54 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Then int(float) can be defined by deferring to trunc()
-- as opposed to round().
That part is new and represents some progress. If I understand it
correctly, it means that we won't have both __int__ and __trunc__
magic
On Jan 27, 2008 10:43 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
- trunc(), round(), floor() and ceil() should all be built-ins,
corresponding to __trunc__, __round__, __floor__ and __ceil__. Then we
have the four standard ways to go from Reals to Integers, which are
properly extensible for
Guido van Rossum wrote:
On Jan 27, 2008 9:26 AM, Andrea Griffini [EMAIL PROTECTED] wrote:
Anyway I want just to say that if implicit conversion from float
to integer goes away then what happens to formatting conversion ?
Removing that too IMO would break a lot of code and it's IMO very
If I'm following this discussion properly, the advantage of trunc() is
that a Real-class-that-isn't-float can define a __trunc__ that can
return an Integer-class-that-isn't-int, right?
Depends on what you compare to. Compared to int(), the advantage is
that trunc() sends a clear message what
[GvR]
- trunc(), round(), floor() and ceil() should all be built-ins,
corresponding to __trunc__, __round__, __floor__ and __ceil__.
In Py2.6, what will the signatures be?
Last I heard, ceil() and floor() were still going to be float--float.
Raymond
On Jan 27, 2008 11:54 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
If I'm following this discussion properly, the advantage of trunc() is
that a Real-class-that-isn't-float can define a __trunc__ that can
return an Integer-class-that-isn't-int, right?
Depends on what you compare to.
On Jan 27, 2008 12:12 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[GvR]
- trunc(), round(), floor() and ceil() should all be built-ins,
corresponding to __trunc__, __round__, __floor__ and __ceil__.
In Py2.6, what will the signatures be?
Last I heard, ceil() and floor() were still
Michael Urman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| 2) The semantics of int() are fuzzy; even non-numeric types
| (strings) are handled
One could just as well say that the semantics of float() are fuzzy since it
also handles strings.
The actual claim seems to have been
Paul Moore schrieb:
On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
int has to be a builtin because it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it probably depends on how often they're
used.
-On [20080126 09:43], Georg Brandl ([EMAIL PROTECTED]) wrote:
Paul Moore schrieb:
- int() has to stay in builtins for obvious reasons.
- put *all* of trunc, ceil, floor, round into math.
That, and making int(float) == int(trunc(float)) seems like reasonable
behavior to me as a person not
Terry Reedy wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Does no-one thinks it means round(f) either?
Not me. Int should truncate, so trunc() not needed unless is does
something different.
Like returning a value of the same type as the input?
On Jan 25, 2008 11:21 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
... int() for making ints from the non-fractional
portion of a float.
This interpretation implies that complex should provide __float__() to
return the non-imaginary portion of a complex number. Is that what you
intend?
--
Jeffrey Yasskin wrote:
This interpretation implies that complex should provide __float__() to
return the non-imaginary portion of a complex number. Is that what you
intend?
No, please don't. If somebody wants to implement __float__ for complex
numbers please define it as hypot(complex) /
On Jan 26, 2008 12:43 AM, Georg Brandl [EMAIL PROTECTED] wrote:
That, and making int(float) == int(trunc(float)) seems like reasonable
behavior to me as a person not involved in the discussion.
That's the only position in this discussion that I don't understand.
Although int() and trunc() would
[Christian Heimes]
In my opinion float(complex) does do the most sensible thing. It fails
and points the user to abs().
Right.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I've been
advocating trunc() under the assumption that int(float) would be
deprecated and eliminated as soon as practical
And how much code would break for basically zero benefit?
This position is totally nuts.
There is *nothing* wrong with int() as it stands now. Nobody has
problems with
On Jan 26, 2008 2:46 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Christian Heimes]
In my opinion float(complex) does do the most sensible thing. It fails
and points the user to abs().
Right.
To elaborate the point I was trying to make: If float() does not mean
the float part of and
Jeffrey Yasskin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
|| To elaborate the point I was trying to make: If float() does not mean
| the float part of
The 'float part' of a complex number is meaningless since both components
of a complex are floats (in practice, or reals in
On Jan 26, 2008 2:53 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Jeffrey]
I've been
advocating trunc() under the assumption that int(float) would be
deprecated and eliminated as soon as practical
And how much code would break for basically zero benefit?
We'll see. Jeffrey did say
. You may disagree, but that doesn't make it nuts.
Too many thoughts compressed into one adjective ;-)
Deprecating int(float)--int may not be nuts, but it is disruptive.
Having both trunc() and int() in Py2.6 may not be nuts, but it is duplicative
and confusing.
The original impetus for
Jeffrey Yasskin wrote:
On Jan 24, 2008 1:11 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[...]
One of my goals for trunc() is to replace the from-float use of int(),
even though we can't remove it for backward-compatibility reasons. PEP
3141 says:
Because the int() conversion
2008/1/25, Jeffrey Yasskin [EMAIL PROTECTED]:
decision comes to be that int(float) should be blessed as a correct
way to truncate a float, I'd agree with Raymond that trunc() is just
duplication and should be eliminated. I'd, of course, rather have a
spelling that says what it means. :)
Raymond Hettinger python at rcn.com writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3.
No one will be surprised (even folks who just use Excel or VB). It
is foolhardy to be a purist and rage against the existing art:
Well, for what it's worth, here are MySQL's own
Jeroen Ruigrok van der Werven wrote:
Can I assume we are all familiar with the concept of significant digits and
that we agree that from this point of view 2 != 2.0? And that results such as
the above would be a regression and loss in precision?
Not really, because if someone cares about
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
int() has undefined semantics -- it takes any object and converts it
to an int (a concrete type!)
So, the problem is basically this:
Since
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Does no-one thinks it means round(f) either?
Not me. Int should truncate, so trunc() not needed unless is does
something different.
And I would prefer the float-input-only converters be in math. There is
nothing
Hello,
Two points. Firstly, regarding MySQL as authoritative from a standards
point of view is bound to lead to trouble, since they have always played
fast and loose with the standard for reasons (I suspect) of
implementation convenience.
To that I heartily agree. I was just pointing out
On Jan 25, 2008, at 1:22 PM, Raymond Hettinger wrote:
I wouldn't fret about this too much. Intrepreting int(f) as
meaning truncate has a *long* history in *many* programming
languages. It is a specious argument int(f) is ambiguous.
No one thinks it means ceil(f).
Not that I think my
[I am still recovering, so if I say something totally misinformed I blame my
recovery. :) ]
-On [20080125 15:12], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python 3:0
2.4 ( 2, 3, 2, 2, 2)
2.6 ( 2, 3, 3, 2, 2)
-2.4 (-3, -2, -2, -2, -2)
-2.6 (-3, -2, -3, -2, -2)
Python 2.6:
2.4 (
If the decision comes to be that int(float) should be blessed
as a correct way to truncate a float, I'd agree with Raymond
that trunc() is just duplication and should be eliminated.
Yay, we've make progress!
I'd,of course, rather have a spelling that says what it means. :)
I wouldn't fret
On Jan 25, 2008 9:45 AM, Facundo Batista [EMAIL PROTECTED] wrote:
2008/1/25, Jeffrey Yasskin [EMAIL PROTECTED]:
decision comes to be that int(float) should be blessed as a correct
way to truncate a float, I'd agree with Raymond that trunc() is just
duplication and should be eliminated.
On Jan 25, 2008 5:53 AM, Paul Moore [EMAIL PROTECTED] wrote:
On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
int has to be a builtin because it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it
Paul Moore wrote:
On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
int has to be a builtin because it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it probably depends on how often they're
used.
On 25/01/2008, Facundo Batista [EMAIL PROTECTED] wrote:
- make int(float) an error
-0 (you should be able to convert between builtin datatypes without
the use of a module).
Good point.
+1 to keep it and define exactly the behaviour, and point to math
module in the documentation if you
2008/1/25, Paul Moore [EMAIL PROTECTED]:
- int() has to stay in builtins for obvious reasons.
+1
- put *all* of trunc, ceil, floor, round into math.
+1
- make int(float) an error
-0 (you should be able to convert between builtin datatypes without
the use of a module). +1 to keep it and
On 2008-01-25 21:26, Steve Holden wrote:
Antoine Pitrou wrote:
Raymond Hettinger python at rcn.com writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3.
No one will be surprised (even folks who just use Excel or VB). It
is foolhardy to be a purist and rage against the
On 25/01/2008, Guido van Rossum [EMAIL PROTECTED] wrote:
Does no-one thinks it means round(f) either? That's the main confusion
here (plus the fact that in C it's undefined -- or at some point was
undefined).
Not me. My intuition agrees with Raymond that int means the integer
part of, i.e.
.some pocket calculators have an INT function, defined
as floor(x) when x is positive and ceil(x) when x is negative
That's the mathematical definition. The way they explain
it is dirt simple: return the integer portion of a number.
Some of the calculators that have int() also have frac()
On Fri, Jan 25, 2008 at 11:32:54AM -0800, Guido van Rossum wrote:
Does no-one thinks it means round(f) either?
I don't think so. I often emulate round(f) as int(f + 0.5).
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die,
On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
int has to be a builtin because it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it probably depends on how often they're
used.
Suggestion:
- int() has
Christian Heimes wrote:
Paul Moore wrote:
Suggestion:
- int() has to stay in builtins for obvious reasons.
- put *all* of trunc, ceil, floor, round into math.
- make int(float) an error
Slightly different suggestion:
- define int(float) as int(trunc(float))
In my humble opinion lots
On Jan 25, 2008 4:28 AM, Facundo Batista [EMAIL PROTECTED] wrote:
2008/1/24, Guido van Rossum [EMAIL PROTECTED]:
So you won't be able to construct an int from a float? That sucks (and
is unintuitive).
Yes, you can, but you have to specify how you want it done by using
trunc() or
On Jan 25, 2008 12:45 PM, Facundo Batista [EMAIL PROTECTED] wrote:
Mmm... no. int() is a builtin way to transform the builtin data type
float into the builtin data type float [sic].
There's no correct way for a float to become an integer, but in the
math module you have several ways to do it
Does no-one thinks it means round(f) either? That's the main confusion
here (plus the fact that in C it's undefined -- or at some point was
undefined).
BTW the list of functions considered here should include round() in
addition to ceil(), floor(), and trunc(), even if 2-arg round()
doesn't quite
[GvR]
Does no-one thinks it means round(f) either?
Heck no. The int() and round() functions have been in Lotus and Excel for an
eternity and nobody has a problem learning what those functions do.
Also, the extra argument for round(f, n) makes it clear that it can return
other floats rounded
Antoine Pitrou wrote:
Raymond Hettinger python at rcn.com writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3.
No one will be surprised (even folks who just use Excel or VB). It
is foolhardy to be a purist and rage against the existing art:
Well, for what it's
On Jan 24, 2008 10:36 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Can anyone explain to me why we need both trunc() and int()?
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
int() has undefined
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
No. trunc calls __trunc__, which does whatever it pleases to do.
class A:
... def __trunc__(self):
... return 0
...
a=A()
trunc(a)
0
int() has
On Jan 24, 2008 11:36 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
No. trunc calls __trunc__, which does whatever it pleases to do.
class A:
... def
Raymond Hettinger wrote:
Since something similar is happening to math.ceil and math.floor,
I'm curious why trunc() ended-up in builtins instead of the math
module. Doesn't it make sense to collect similar functions
with similar signatures in the same place?
Traditionally the math module is a
On Jan 24, 2008 12:46 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
int() has undefined semantics -- it takes any object and converts it
to an int (a
On Jan 24, 2008 1:09 PM, Daniel Stutzbach
[EMAIL PROTECTED] wrote:
On Jan 24, 2008 12:46 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
int() has
On Jan 24, 2008 1:11 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Raymond Hettinger]
Since something similar is happening to math.ceil and math.floor,
I'm curious why trunc() ended-up in builtins instead of the math
module. Doesn't it make sense to collect similar functions
with
74 matches
Mail list logo
