Hi Raymond,
On Thu, Jan 24, 2008 at 01:36:14PM -0500, Raymond Hettinger wrote:
> Also, it seems that ABC is starting to evolve from an optional
> tool into something embedded in the language in a way that you
> can't escape it.
>
> I would prefer that it not be on the list of concepts that a
> b
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
>> d
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.
>>> typ
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, be
On Jan 27, 2008 3:37 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> The actual claim seems to have been that the semantics of int()
> 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
> f
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 rea
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
[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 surprise me too much a
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
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 i
> 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
"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 b
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
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() w
[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
___
> 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
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 ve
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 extensibl
On Jan 27, 2008 10:54 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Then int() 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__
> mag
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 t
> Then int() 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: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),
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 9:26 AM, Andrea Griffini <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > - Deprecating int() 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 exa
> [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
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() 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 exa
[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 ar
On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Deprecating int() 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" argume
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 datapoi
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 ast
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
>. 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 faci
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 di
"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 i
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 o
> 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 wit
[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:
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() wo
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) / sqr
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?
-
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 i
-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
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
>> us
> 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 i
"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
nothi
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 pre
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
On 2008-01-25 21:26, Steve Holden wrote:
> Antoine Pitrou wrote:
>> Raymond Hettinger 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 th
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.
Antoine Pitrou wrote:
> Raymond Hettinger 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 wor
[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
>.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()
w
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 opi
Raymond Hettinger 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 two ce
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,
[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
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
> 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 f
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 t
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 elim
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. :)
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;
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
>
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 humbl
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
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
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()
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/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 round() or ceil() or floor(). (In 3.0, round(x) will return
> an int
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
> >
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(
[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 similar signatures in the same place?
[Christian Heimes]
> Traditionally t
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
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 i
>> 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.
Since something similar is happening to math.ceil and math.floor,
I'm curious why trunc()
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
> 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
>
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 seman
Can anyone explain to me why we need both trunc() and int()?
We used to be very resistant to adding new built-ins and
magic method protocols. In days not long past, this would
have encountered fierce opposition.
ISTM that numbers.py has taken on a life of its own and
is causing non-essential off
80 matches
Mail list logo
