Re: [Python-Dev] trunc()
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, because often the quoted text is in a different thread. His mails don't have any indication they're a reply at all - not even so much as a Re: in the Subject. Even Outlook Express isn't *that* broken; I suspect he's not actually using the 'reply' button in his mailer. ___ 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
Re: [Python-Dev] trunc()
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 disconnected than most, because often the quoted text is in a different thread. His mails don't have any indication they're a reply at all - not even so much as a Re: in the Subject. Even Outlook Express isn't *that* broken; I suspect he's not actually using the 'reply' button in his mailer. Raymond, I don;t know why everyone's talking about you as though you weren't reading the thread and able to answer questions. Though I *have* sometimes wondered why your posts lack attributions for the quotes. I see from your headers you have, at least some of the time, been posting via gmane using mirapoint webmail direct, whatever that is. Perhaps that's the problem? sticking-with-t'bird-despite-its-faults-ly y'rs - steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
Re: [Python-Dev] trunc()
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.
type(object)
type 'type'
list({1:2, 3:4})
[1, 3]
set({1:2, 3:4})
set([1, 3])
[...]
Surely the real issue here is that int() grew up purely as a conversion
function, and metamorphosed into a type when the classic classes were
moved into the background.
A brief scan of the 2.4 library (the nearest to hand) shows no uses of
int() without an argument in the top level modules. There's clearly no
point calling int() with a literal integer argument, so its uses for
conversion clearly dominate its use as a pure type constructor.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
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
Re: [Python-Dev] trunc()
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 number itself. You think of it as a string of digits and chop off the part after the point, then turn what's left back into a number. If negative floats were represented in two's complement, for example, then chopping off the digits after the point would give a result more like floor than trunc. -- Greg ___ 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
Re: [Python-Dev] trunc()
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 duplicative and confusing. The original impetus for facilitating a new Real type being able to trunc() into a new Integral type may not be nuts, but the use case seems far fetched (we're never had a feature request for it -- the notion was born entirely out of numeric tower considerations). 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. The idea that trunc() is beneficial may not be nuts, but it is certainly questionable. In short, the idea may not be nuts, but I think it is legitimate to suggest that it is unnecessary and that it will do more harm than good. All this reminds me a lot of discussions we've had when we needed a new way to spell out string.join(). In the end, we ended up adding a method to strings (thanks to Tim Peters, IIRC) instead of adding a builtin join(). Since all of the suggested builtins are only meant to work on floats, why not simply add methods for them to the float object ?! E.g. x = 3.141 print x.trunc(), x.floor(), x.ceil() etc. This approach also makes it possible to write types or classes that expose the same API without having to resort to new special methods (we have too many of those already). Please consider that type constructors have a different scope than helper functions. Helper functions should only be made builtins if they are really really useful and often needed. If they don't meet this criteria, they are better off in a separate module. I don't see any of the suggested helper functions meeting this criteria and we already have math.floor() and math.ceil(). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 28 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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
Re: [Python-Dev] trunc()
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 probably depends on how often they're used. Suggestion: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. - make int(float) an error I like all of your suggestions except the last one. Remember the problem with a/b depending on whether b happened to be a float or an int? I think you'll be creating a very similar problem here. In my opinion int(foo) should do its best to turn foo into an int with *predictable* behavior. The least surprising behavior for int(float) is probably trunc(float). Personally I prefer round(float), but I doubt it is worth breaking code and retraining everybody. -- Russell ___ 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
Re: [Python-Dev] trunc()
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
Re: [Python-Dev] trunc()
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 isn't worth more energy at this point; I see a use for trunc() separate from int() and I really don't care if Raymond doesn't see it. Let's move trunc() to the math module and be done with it, leaving round() a built-in with both the one- and two-argument versions intact. 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, because often the quoted text is in a different thread. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 surprise me too much as it is not a common (American) English word. Even to adults, the word has other meanings: http://en.wikipedia.org/wiki/Truncation_%28disambiguation%29 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. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
Re: [Python-Dev] trunc()
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 better off with lround(x). They know that the cast truncates, and generally that they actually wanted to round, but the type they wanted to get to was foremost in their mind, so they didn't bother to think about it a little and write what they really wanted. It's not that they're confused; it's that they're accepting a default that shouldn't be a default. Your other points seem to have been answered already, although people will disagree on how compelling the answers are, so I won't repeat them here. -- 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
Re: [Python-Dev] trunc()
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 astonishing how many major rounding and division bugs are found by newbies. Christian ___ 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
Re: [Python-Dev] trunc()
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] You're beginning to repeat your argument; none of that was new. One other thought: In Python, it has been nice that we have simple type coercions using the type name: * set(p)--qcan accept a list, tuple, string, or any iterable and make a set * int(p)--q can accept an int, long, float, or string and make an int * float(p)--q can accept an int, long, float, or string and make an int * list(p)--qcan accept a list, tuple, string, or any iterable and make a list * unicode(p)-- can accept a str, buffer, or unicode object and make a unicode object It's a bit weird to decide that int() needs to lose that capability so we get generalized Integrals as output. What's wrong with coercion to a concrete type? Let me get back to you on that. I first want to point out that you snipped the core of my argument in the post you otherwise quoted. I will repeat it here because I would like your explicit reaction: [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 different type that happens to define __int__, perhaps a custom date/time type (I believe mxDateTime supports this). Can I assume that you agree with this? That would be progress. Coming back to your argument that other types have a constructor that takes all kinds of arguments, I'd like to point out that they all have restrictions too (except for str()): list() and tuple() only accept iterables, float() only accepts strings and certain numbers (not complex), and so on. Taking the latter as an example: float(0j) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't convert complex to float; use abs(z) I think that (eventually) int(0.0) could do something similar: int(0.0) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't convert float to int; use round(x) or trunc(x) But see below. Yet another (minor) argument that has always made me uncomfortable with int() == trunc(): the % operator. I think it's a big improvement over C that Python's % operator is defined as x%y == x - y*floor(x/y) # where / is real division rather than C's division, which uses trunc() instead of floor(). In C this nicely meshes with the definition of int(): you can define x%y as x - y*(int)(x/y); but not so in Python. I don't want to use this as an argument for defining int(x) as floor(x), but I do want to point out that it has always given me a twinge of discomfort. FInally, there's the one way argument. That's a nice slogan, but doesn't really hold anyways in practice. To copy a list, we can write either L[:] or list(L). To get the keys of a dict, we can write either D.keys() or list(D). To convert a number to a string we can write either %g % X or str(X). For octal we can write %#o % X or oct(X). To convert a unicode string to UTF-8, we can write either U.encode(utf8) or str(U, utf8). And so on. In many cases, these notations aren't exactly the same in semantics (e.g. list(X) always returns a list, X[:] returns whatever sequence type X is), but nevertheless they have large areas of overlap. This is how I see trunc() and int() live together. After all that, here's my current proposal: - 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 for it would have worked better if it was made 18 years ago. - 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 folks who write their own number types. (We can't control how folks implement __round__, but we can document expected behavior -- that's how we treat __add__ and all other operators too, after all.) - In the docs (especially for beginners) we recommend that users write trunc() instead of int(), emphasizing that trunc() ensures the argument is a number, while suggesting int(x) for conversion from strings. But the implementation won't chastise users by issuing annoying warnings. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] trunc()
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 for it would have worked better if it was made 18 years ago. Also what happens with %i % 3.14 ? We incidentally found a problem with a script using python 2.5 because apparently the % formatting operator doesn't use int() for doing the conversion (to be more specific if the float is too large for a 32-bit integer then the format operator chokes while the int() operator returns a long). 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 difficult to help fixing that. Andrea ___ 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
Re: [Python-Dev] trunc()
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 0. I realize that in practice this kills the idea. The purist argument for it would have worked better if it was made 18 years ago. Also what happens with %i % 3.14 ? We incidentally found a problem with a script using python 2.5 because apparently the % formatting operator doesn't use int() for doing the conversion (to be more specific if the float is too large for a 32-bit integer then the format operator chokes while the int() operator returns a long). 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 difficult to help fixing that. Well, it seems like it would be as easy to make some formatting conversions raise a warning on float inputs as it would be to make int() do it. But I think you're safe here; it doesn't look like either will be deprecated. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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
Re: [Python-Dev] trunc()
[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 common. Of course, those floating point repr questions are common, but that wasn't the issue here. The trunc() protagonists are contending that the int(f) function will be confused with the round(f, n) function. I've never seen than come up, ever. Raymond ___ 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
Re: [Python-Dev] trunc()
[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 different type that happens to define __int__, perhaps a custom date/time type (I believe mxDateTime supports this). Can I assume that you agree with this? That would be progress. I agree that it provides a cue that that input is Real. I don't agree that that has any value. We had a lot of tools that can accept multiple input types. For instance, float() can accept a string or number. We could do like C and split-out the atof() functionality but that just makes two functions where one would suffice. Yet another (minor) argument that has always made me uncomfortable with int() == trunc(): the % operator. I think it's a big improvement over C that Python's % operator is defined as x%y == x - y*floor(x/y) # where / is real division rather than C's division, which uses trunc() instead of floor(). In C this nicely meshes with the definition of int(): you can define x%y as x - y*(int)(x/y); but not so in Python. I don't want to use this as an argument for defining int(x) as floor(x), but I do want to point out that it has always given me a twinge of discomfort. It hasn't bugged me much, but I do understand. After all that, here's my current proposal: - 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 for it would have worked better if it was made 18 years ago. pretty radical is what I meant when I said it's nuts ;-) This is a major piece of progress. Most of the prior proposal was predicated on int(float) being deprecated. - 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 folks who write their own number types. (We can't control how folks implement __round__, but we can document expected behavior -- that's how we treat __add__ and all other operators too, after all.) ISTM, you really don't need trunc() in this mix. The ceil() and floor() functions do an excellent job of convering most use cases. The overlap of trunc() and int() just isn't worth it. There's the mental cost of having to explain the difference on day one to every beginner. There's the back end cost of every class that has __int__ also needing to decide whether to provide __trunc__ which will typically be the same thing. In time, I believe it will become self-evident that having both int() and trunc() is a wart. If trunc() goes into 2.6 and 3.0, then we're going to have to live with this for a long time. Purity may suggest that you need trunc(). Practicality says it isn't worth the cost. At least we've made important progress by saving int(float). Raymond ___ 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
Re: [Python-Dev] trunc()
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 0. I realize that in practice this kills the idea. The purist argument for it would have worked better if it was made 18 years ago. Also what happens with %i % 3.14 ? We incidentally found a problem with a script using python 2.5 because apparently the % formatting operator doesn't use int() for doing the conversion (to be more specific if the float is too large for a 32-bit integer then the format operator chokes while the int() operator returns a long). That's quite a separate issue. Please ses http://bugs.python.org/issue1742669. 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 difficult to help fixing that. The formatting code could assign specific meanings. I suspect though that it was never meant to be possible to use %d with a float -- it just is one of the artifacts of using implicit conversion, and one not well-thought through. Note: %.0f % 3.99 '4' %d % 3.99 '3' I think the latter is wrong and confusing. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 chosen mapping to be implemented, so long as it results in an integer, so (1) is only guaranteed true for the builtin types. This leaves us with (2) which seems strongly tied to string parsing (as __index__ resolved the other common X - integer case). I see one main argument against: *) trunc() results in duplication at best, zealous deprecation at worst Given that the deprecation or removal of int(2.3) has been dropped, the argument is about pointless duplication. What problem is trunc() supposed to solve if it does to floats what int() does now? I've done some initial code searches for: lang:python int(, and I've seen three primary uses for calling int(x): a) parsing strings, such as from a user, a config file, or other serialized format b) limiting the input to a function to an integer, such as in a calendar trying to ensure it has integer months c) truncation, such as throwing away sub-seconds from time.time(), or ensuring integer results from division It's unclear to me whether (b) could be better served by more type-specific operations that would prevent passing in strings, or whether uses like (c) often have latent bugs due to truncation instead of rounding. If trunc() is to clarify round vs. integer-portion, it's something people learn -- the general lack of comments in (c) usages indicates nobody considers it special behavior. If it's to clarify the argument's type (the parsing of strings vs. getting integers from other numeric types), would separating parsing from the int (and float) constructors also solve this? Is the aim to clean up the following fake example? (Real world uses of map(int, ...) seem almost uniformly related to string parsing.) map(int, (42, 6.022, 2**32)) [42, 6, 4294967296L] -- Michael Urman ___ 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
Re: [Python-Dev] trunc()
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 make no such assumption -- x could be a string, or it could be a totally different type that happens to define __int__, perhaps a custom date/time type (I believe mxDateTime supports this). Can I assume that you agree with this? That would be progress. I agree that it provides a cue that that input is Real. I don't agree that that has any value. We had a lot of tools that can accept multiple input types. For instance, float() can accept a string or number. We could do like C and split-out the atof() functionality but that just makes two functions where one would suffice. All I claim is that it has *some* value for me. If it doesn't have value for you, that doesn't make it worthless. Yet another (minor) argument that has always made me uncomfortable with int() == trunc(): the % operator. I think it's a big improvement over C that Python's % operator is defined as x%y == x - y*floor(x/y) # where / is real division rather than C's division, which uses trunc() instead of floor(). In C this nicely meshes with the definition of int(): you can define x%y as x - y*(int)(x/y); but not so in Python. I don't want to use this as an argument for defining int(x) as floor(x), but I do want to point out that it has always given me a twinge of discomfort. It hasn't bugged me much, but I do understand. Progress. After all that, here's my current proposal: - 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 for it would have worked better if it was made 18 years ago. pretty radical is what I meant when I said it's nuts ;-) This is a major piece of progress. Most of the prior proposal was predicated on int(float) being deprecated. Good. - 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 folks who write their own number types. (We can't control how folks implement __round__, but we can document expected behavior -- that's how we treat __add__ and all other operators too, after all.) ISTM, you really don't need trunc() in this mix. The ceil() and floor() functions do an excellent job of convering most use cases. Not really. You'd have to use an if predicated on the sign to emulate trunc() using ceil() and floor(). Or something like sign(x) * floor(abs(x)) -- but we don't have sign(). The overlap of trunc() and int() just isn't worth it. There's the mental cost of having to explain the difference on day one to every beginner. There's the back end cost of every class that has __int__ also needing to decide whether to provide __trunc__ which will typically be the same thing. In time, I believe it will become self-evident that having both int() and trunc() is a wart. If trunc() goes into 2.6 and 3.0, then we're going to have to live with this for a long time. Purity may suggest that you need trunc(). Practicality says it isn't worth the cost. At least we've made important progress by saving int(float). I don't see much cost for end users at all. It's not like trunc() represents a difficult concept. Having trunc() in addition to ceil(), floor() and round() creates a nicely complete set of float-int conversions. Then int(float) can be defined by deferring to trunc() -- as opposed to round(). My proposal stands (less any talk of deprecation of int(float)). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 ___ 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
Re: [Python-Dev] trunc()
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 (strings) are handled Yet there will be a __trunc__ that will allow any chosen mapping to be implemented, so long as it results in an integer, so (1) is only guaranteed true for the builtin types. We can easily add docs to the Real ABC indicating that __trunc__ *should* implement a certain semantics, just like we do (or should do) for __add__ and everything else. While this doesn't provide a hard guarantee in the presence of non-conforming implementations, it's as good as it gets anywhere in Python. Given that __int__ may be implemented for things that aren't reals (like dates), it's much harder to prescribe what it *should* do. This leaves us with (2) which seems strongly tied to string parsing (as __index__ resolved the other common X - integer case). I see one main argument against: *) trunc() results in duplication at best, zealous deprecation at worst Given that the deprecation or removal of int(2.3) has been dropped, the argument is about pointless duplication. To some it's pointless. To others there's a fine point to it. What problem is trunc() supposed to solve if it does to floats what int() does now? I've done some initial code searches for: lang:python int(, and I've seen three primary uses for calling int(x): a) parsing strings, such as from a user, a config file, or other serialized format b) limiting the input to a function to an integer, such as in a calendar trying to ensure it has integer months c) truncation, such as throwing away sub-seconds from time.time(), or ensuring integer results from division It's unclear to me whether (b) could be better served by more type-specific operations that would prevent passing in strings, or whether uses like (c) often have latent bugs due to truncation instead of rounding. Case (b) should be using index() instead. Most likely the code either predates index() or needs to be compatible with Python versions that don't have it, or the programmer wasn't aware of index(), which hasn't received a lot of publicity. If trunc() is to clarify round vs. integer-portion, it's something people learn -- the general lack of comments in (c) usages indicates nobody considers it special behavior. If it's to clarify the argument's type (the parsing of strings vs. getting integers from other numeric types), would separating parsing from the int (and float) constructors also solve this? But there's a long-standing tradition that all numeric types in Python accept a string as argument. This was just added to decimal too. Is the aim to clean up the following fake example? (Real world uses of map(int, ...) seem almost uniformly related to string parsing.) map(int, (42, 6.022, 2**32)) [42, 6, 4294967296L] That's an artificial example and hence it is impossible to derive the intent of the programmer. Heterogeneous lists are pretty rare. Let me give another artificial example. Suppose I have a need to implement floats and ints that print themselves in hex. I can make it so that this property is maintained across addition etc. without having to change the code that *uses* these numbers. But code that uses int() to convert a float to an int will lose the property. If that code used trunc() instead I can provide a __trunc__ on my hexfloat that returns a hexint. QED. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 methods. That's a good thing. A single type wouln't need both. But int() should still try both, because it doesn't make sense for e.g. a date type to have to define __trunc__ for conversion to an int. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 folks who write their own number types. (We can't control how folks implement __round__, but we can document expected behavior -- that's how we treat __add__ and all other operators too, after all.) 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? In that case, why not have the Real ABC grow trunc(), ceil(), floor(), and round() methods (replacing the __ varieties), and get rid of the builtins/math-module functions? x.trunc() is just as clear as trunc(x), and doesn't require a builtin. The syntax when used on float literals is ugly (2.56 .round()), but there's no use case for these methods on literals (just write 3). 2to3 could handle this conversion pretty easily in most cases, so there won't be much breakage. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ 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
Re: [Python-Dev] trunc()
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 difficult to help fixing that. The formatting code could assign specific meanings. I suspect though that it was never meant to be possible to use %d with a float -- it just is one of the artifacts of using implicit conversion, and one not well-thought through. Note: %.0f % 3.99 '4' %d % 3.99 '3' I think the latter is wrong and confusing. format() has the same issue, for the same reason: format(3.9, 'f') '3.90' format(3.9, 'd') '3' I never noticed this before, and it's a definite error. PEP 3101 says the valid types for float are 'eEfFgGn%' and an empty string. I'll remove the integer conversion in the float formatter. Eric. ___ 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
Re: [Python-Dev] trunc()
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 its semantics is. In that case, why not have the Real ABC grow trunc(), ceil(), floor(), and round() methods (replacing the __ varieties), and get rid of the builtins/math-module functions? x.trunc() is just as clear as trunc(x), and doesn't require a builtin. +1. Students just asked me why len() is not a method, and I didn't know a good answer; the same holds for many other builtins. This is a clear candidate for a method, IMO. The syntax when used on float literals is ugly (2.56 .round()), but there's no use case for these methods on literals (just write 3). Actually, it works fine for float literals: py 2.45.round() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'float' object has no attribute 'round' It's only int literals which have a problem with methods, but then, you won't call any of these on an int literal, normally. Regards, Martin ___ 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
Re: [Python-Dev] trunc()
[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 ___ 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
Re: [Python-Dev] trunc()
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. Compared to int(), the advantage is that trunc() sends a clear message what its semantics is. In that case, why not have the Real ABC grow trunc(), ceil(), floor(), and round() methods (replacing the __ varieties), and get rid of the builtins/math-module functions? x.trunc() is just as clear as trunc(x), and doesn't require a builtin. +1. Students just asked me why len() is not a method, and I didn't know a good answer; the same holds for many other builtins. This is a clear candidate for a method, IMO. Well, there's the generic functions line of thought, which isn't quite dead yet. And there's the idea that the built-in function can check that the result has a certain type, like len(), which insists on returning an int. But mostly it's because I find things like len(x), round(x) and cos(x) read more natural than method notation. It builds on a long tradition in math and applied math in programming language -- at least round() and cos() do, and so does trunc(). IOW it's a matter of aesthetics, and will never be explainable to everyone's satisfaction. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 going to be float--float. When imported from math, yes, for 2.5 compatibility. If we add builtins, the builtins won't have this restriction. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 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 b. that some people might think the latter means the same as the former. Possibility a is easy taken care of by documentation, especially when the behavior is what people expect. 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. 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. 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. tjr ___ 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
Re: [Python-Dev] trunc()
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. Suggestion: - 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 involved in the discussion. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] trunc()
-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 involved in the discussion. +1 from my side for the above. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ 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
Re: [Python-Dev] trunc()
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? int(), being a call to a type, should never return a value of another type. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
Re: [Python-Dev] trunc()
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? -- 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
Re: [Python-Dev] trunc()
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) / sqrt(c.real**2 + c.img**2). In my opinion float(complex) does do the most sensible thing. It fails and points the user to abs(). float(complex(1,1)) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't convert complex to float; use abs(z) abs(complex(1,1)) 1.4142135623730951 ___ 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
Re: [Python-Dev] trunc()
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 still have very slightly different behaviors, they seem too close together (identical on most common types) to be compatible with only one way to do it. I've been advocating trunc() under the assumption that int(float) would be deprecated and eliminated as soon as practical (with an error message similar to float(complex)). Could one of the people in favor of keeping both explain why they think that's a good idea? -- 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
Re: [Python-Dev] trunc()
[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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
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 it. The tools is ubiquitous in other languages, spreadsheets, and calculators. Raymond ___ 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
Re: [Python-Dev] trunc()
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 should not take a complex argument (which I completely agree with), then int() does not mean the int part of and should not take a float argument. Even assuming that's correct, I'm not certain that it's worth breaking (well, deprecating) backwards compatibility to achieve a more consistent set of functions in this case. I think it is, but I'm happy to leave that point up to the rest of the list (which does seem to be leaning against it). -- 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
Re: [Python-Dev] trunc()
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 theory). The same is true in polar representation. | and should not take a complex argument (which I | completely agree with), then int() does not mean the int part of and | should not take a float argument. The 'integer (int) part' of a float/rational/real is established thru decades of usage. Your consequent is false and in no way follows from your antecendent. tjr ___ 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
Re: [Python-Dev] trunc()
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 deprecated and as soon as practical. A -3 warning in 2.6 could do wonders. This position is totally nuts. Hold it right there. You may disagree, but that doesn't make it nuts. 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 different type that happens to define __int__, perhaps a custom date/time type (I believe mxDateTime supports this). There is *nothing* wrong with int() as it stands now. Nobody has problems with it. The tools is ubiquitous in other languages, Talk to C++ experts. They have a huge beef with C's confusing use of casts for two different purposes: reinterpretation of the same bit pattern vs. value conversion. Python problem isn't quite the same, but I still really wish I had followed Pascal's lead instead of C's here: Pascal requires you to use trunc() to convert a real to an integer. (BTW Pascal also had the division operator right, unlike C, and we're finally fixing this in Py3k by following Pascal's nearly-40-year-old lead.) If we had done it that way, we wouldn't have had to introduce the index() builtin and the corresponding infrastructure (__index__ and a whole slew of C APIs). spreadsheets, and calculators. I don't think that Excel should be held up as a shining example for Python. At least, that would be quite a change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
. 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 facilitating a new Real type being able to trunc() into a new Integral type may not be nuts, but the use case seems far fetched (we're never had a feature request for it -- the notion was born entirely out of numeric tower considerations). 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. The idea that trunc() is beneficial may not be nuts, but it is certainly questionable. In short, the idea may not be nuts, but I think it is legitimate to suggest that it is unnecessary and that it will do more harm than good. I don't think that Excel should be held up as a shining example for Python. It is simply a datapoint. We don't care why they chose int() for truncation. The important thing is the subsequent user experiences which indicates that people do not have a problem with it. When it comes to int() and round(), people just get it. I've taught spreadsheets to a lot people and no one has ever construed int() as meaning round(). What was your experience with 18 years of python? Was it a recurring a point of confusion? On the newsgroup, helplist, and tutorial list, I never seen this come up as problem. I looked in other places for corroboration. My HP-12C has intg and frac buttons. In BASIC, int() means to return the integer part of a floating point number. The surprise find was that int() in Matlab and Maple means integrate :-) FWIW, Perl's int() does what ours currently does. One other thought: In Python, it has been nice that we have simple type coercions using the type name: * set(p)--qcan accept a list, tuple, string, or any iterable and make a set * int(p)--q can accept an int, long, float, or string and make an int * float(p)--q can accept an int, long, float, or string and make an int * list(p)--qcan accept a list, tuple, string, or any iterable and make a list * unicode(p)-- can accept a str, buffer, or unicode object and make a unicode object It's a bit weird to decide that int() needs to lose that capability so we get generalized Integrals as output. What's wrong with coercion to a concrete type? Raymond ___ 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
Re: [Python-Dev] trunc()
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 implemented by float (and by decimal.Decimal) is equivalent to but less explicit than trunc(), let's remove it. (Or, if that breaks too much, just add a deprecation warning.) That needs to be updated and implemented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. It seems strange to me that a release that has the avowed intention of producing a more rational language by breaking backwards compatibility should start out with deprecation warnings of this type. What's next: This isn't Perl when someone tries to add a number and a string? Surely the place to raise warnings is in 2to3. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
Re: [Python-Dev] trunc()
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. :) Mmm... no. int() is a builtin way to transform the builtin data type float into the builtin data type float. There's no correct way for a float to become an integer, but in the math module you have several ways to do it (floor, ceil, round, trunc, choose the one that you want, but you're notified wink/2 that there're different ways to do it). -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Re: [Python-Dev] trunc()
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 two cents: mysql create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from t; +--+ | a| +--+ |1 | |2 | | -2 | | -1 | +--+ 4 rows in set (0.00 sec) ___ 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
Re: [Python-Dev] trunc()
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 precision to that extent they won't be using binary floats anyway (they'll be using Decimal, or something like it). Besides, for trunc, ceil and floor, it's all zeroes after the decimal point by definition (no matter how many significant digits you started with). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] trunc()
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 int(o) must return an int, you're precluded from defining a new Real class with an __int__() method that returns an instance of some new Integral class that isn't an int. And the proposed solution is: Introduce trunc(o) which calls o.__trunc__() which can return any Integral type. And, client code must use trunc() instead of int(); otherwise, the two new numeric types won't be exercised. Is that basically what trunc() is all about -- a variant of int() that can return something other than an int type -- something that behaves just like the new math.floor() for positive numbers and math.ceil() for negative numbers? If so, I think we would be *much* better-off leaving trunc() out entirely and seeing if any use cases arise that aren't handled by math.floor() and math.ceil() with their precise semantics, unambigous naming, and ability to handle generic Reals and Integrals. The existence of trunc() clashes so severely with existence of int(), that we need to be damned sure that there are real-world, worthwhile problems that are not readily solved with floor() and ceil() for rounding Reals into Integrals or with int() for making ints from the non-fractional portion of a float. Raymond ___ 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
Re: [Python-Dev] trunc()
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 second-class, really, about functions in modules. Just more specific. tjr ___ 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
Re: [Python-Dev] trunc()
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 that implicit conversion of float to int did not always use the moral equivalent of trunc() under all programming platforms. That said, I don't think it's that important, it's just something you have to learn. Regards Antoine. ___ 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
Re: [Python-Dev] trunc()
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 opinion will have any weight in this discussion, but I'd agree that int has a long history not likely to be misinterpreted when applied to real numbers. Quoting from Graham, Knuth and Patashnik Concrete Mathematics...2nd edition page 67: We start by covering the floor (greatest integer) and ceiling (least integer) functions, which are defined for all real x... ...some pocket calculators have an INT function, defined as floor(x) when x is positive and ceil(x) when x is negative. The designers of these calculators probably wanted their INT function to satisfy the identity INT(-X) = -INT(X). But we'll stick to our floor and ceiling functions, because they have even nicer properties than this. jared ___ 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
Re: [Python-Dev] trunc()
[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 ( 2.0, 3.0, 2.0, 2, 2) 2.6 ( 2.0, 3.0, 3.0, 2, 2) -2.4 (-3.0, -2.0, -2.0, -2, -2) -2.6 (-3.0, -2.0, -3.0, -2, -2) Am I the only one who wonders about the sudden change in decimal significance? Especially given the fact that the ISO C standard specifies floor(), for example, as returning a floating point value and the above in Python 3.0 deviates to just returning an integer. Which is also different from 2.5's behaviour. 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? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ 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
Re: [Python-Dev] trunc()
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 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). 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: SQL: The INT() function returns its numeric argument with any fractional digits removed and truncates all digits to the right of the decimal point. www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm VB: Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value. http://msdn2.microsoft.com/en-us/library/xh29swte.aspx Excel: The Int function returns the integer portion of a number. http://www.techonthenet.com/excel/formulas/int.php These docs suggest where the thinking has gone wrong. Writing int(f) doesn't mean arbritrary select one of round|ceil|floor|trunc as a way of getting to an integer; instead, it means return the integer portion (non-fractional component) of a number. The latter definition seems common and is entirely unambiguous. Raymond ___ 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
Re: [Python-Dev] trunc()
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. I'd, of course, rather have a spelling that says what it means. :) Mmm... no. int() is a builtin way to transform the builtin data type float into the builtin data type float. I assume you meant int instead of your second float. There doesn't have to be a way to convert from every builtin type to every other builtin type. Take dict(float), for example. Further, if there is a conversion, no law says it has to be named the same as the target type. If there are two plausible ways to get from the source to the target, using just the target's name to pick out one of them is really a terrible idea. But, just because the designers of C made a bad decision that we've inherited, doesn't mean that it's a terrible idea to keep it. As Nick said, defining int(float) as truncation has a long history, and there are some obvious costs to breaking away from that. I think it is time to correct the mistake, but it's not an open and shut case. -- 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
Re: [Python-Dev] trunc()
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 probably depends on how often they're used. Suggestion: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. - make int(float) an error I'd deal with Facundo's objection that you should be able to convert between builtin datatypes without the use of a module by leaving trunc in the builtins, but it looks like I'm in the minority here. 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. I'd, of course, rather have a spelling that says what it means. :) The only fly in the ointment is that 2to3 can't handle the semantic issues around converting int(n) to math.trunc(n) because it can't detect the type of n. So why not make int(float) warn in -3 mode on 2.6, and then let 2to3 do the conversion (on the basis that 2to3 should only be run on code that is -3 warning free)? I'd be happy with that too. -- 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
Re: [Python-Dev] trunc()
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. 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 of people expect int(-2.5) == -2 and int(2.5) == 2. Or in other words: int(float) chops of the digits after the dot. As far as I can see float.__int__ already behaves like int(trunc(float)) for n in (2.4, 2.6, -2.4, -2.6): ... print(n, (math.floor(n), math.ceil(n), round(n), trunc(n), int(n))) ... 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 ( 2.0, 3.0, 2.0, 2, 2) 2.6 ( 2.0, 3.0, 3.0, 2, 2) -2.4 (-3.0, -2.0, -2.0, -2, -2) -2.6 (-3.0, -2.0, -3.0, -2, -2) Christian ___ 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
Re: [Python-Dev] trunc()
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 want better control over the conversion. Sonds good. Paul ___ 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
Re: [Python-Dev] trunc()
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 define exactly the behaviour, and point to math module in the documentation if you want better control over the conversion. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Re: [Python-Dev] trunc()
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 existing art: Well, for what it's worth, here are MySQL's own two cents: mysql create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from t; +--+ | a| +--+ |1 | |2 | | -2 | | -1 | +--+ 4 rows in set (0.00 sec) 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. Second, that example isn't making use of the INT() function. I was going to show you result of taking the INT() of a float column containing your test values. That was when I found out that MySQL (5.0.41, anyway) doesn't implement the INT() function. What was I saying about standards? FWIW, here's what IBM has to say to this: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r814.htm If the argument is a numeric-expression, the result is the same number that would occur if the argument were assigned to a large integer column or variable. If the whole part of the argument is not within the range of integers, an error occurs. The decimal part of the argument is truncated if present. AFAIK, the INTEGER() function is not part of the SQL standard, at least not of SQL92: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt The way to convert a value to an integer is by casting it to one, e.g. CAST (X AS INTEGER). The INT() function is basically a short-cut for this. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 25 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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
Re: [Python-Dev] trunc()
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. trunc(), when dealing with a numeric argument. (int(string) is a different matter, and I have no problem having different intuitions for that. So sue me) I'd like to keep trunc (as math.trunc) for those cases where I want to be completely explicit, but it's not a big deal to me. 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 fit. My original message suggested that round go into math as well. It didn't get much comment, though, as everyone latched onto the more controversial suggestion that int(float) be an error - which is the bit I was least concerned about, ironically. Paul. ___ 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
Re: [Python-Dev] trunc()
.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() which has the obvious interpretation. Raymond ___ 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
Re: [Python-Dev] trunc()
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, they just GOSUB without RETURN. ___ 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
Re: [Python-Dev] trunc()
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 to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. - make int(float) an error The only fly in the ointment is that 2to3 can't handle the semantic issues around converting int(n) to math.trunc(n) because it can't detect the type of n. So why not make int(float) warn in -3 mode on 2.6, and then let 2to3 do the conversion (on the basis that 2to3 should only be run on code that is -3 warning free)? Did I miss a requirement here? Paul. ___ 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
Re: [Python-Dev] trunc()
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 of people expect int(-2.5) == -2 and int(2.5) == 2. Or in other words: int(float) chops of the digits after the dot. FWIW, this approach gets a +1 from me (although I'm -0 on taking round() out of builtins - that seems like a pointless incompatibility to me). Yes, blessing 'trunc' as the default mechanism for converting a non-integral number to an integer is somewhat arbitrary, but it's a piece of arbitrariness with a very long history behind it. For that matter, we could even formally define int() as falling back to trunc() if there is no direct conversion (i.e. int knows about the type natively, or the type provides an __int__ method). That way non-integral types could just implement __trunc__ without having to worry about adding __int__ = __trunc__ to the class definition. We would still have operator.index to identify types which can be losslessly converted to a builtin integer. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] trunc()
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 round() or ceil() or floor(). (In 3.0, round(x) will return an int, not a float.) 2008/1/24, Jeffrey Yasskin [EMAIL PROTECTED]: That needs to be updated and implemented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. What I understand here is as int() is ambiguous, in the future if you want to specify how you want to convert a float to int. But ceil and floor returns a float. And round and trunc will return an int. So, how I could convert a float to its upper int? Like this?: trunc(math.ceil(.3)) 1 Like this, in 3.0: math.ceil(2.2) 3 There was a previous thread in which we decided not to change that behavior in 2.6. BTW, int is not giving me a deprecation warning: int(.1) 0 Correct; that's not implemented yet. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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
Re: [Python-Dev] trunc()
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 (floor, ceil, round, trunc, choose the one that you want, but you're notified wink/2 that there're different ways to do it). In keeping with this theme, why not define int() for floats (and other real types) as def __int__(n, method=math.trunc) or something similar, so that, by default, int() provides the same functionality as before (or whatever is decided to be preferred, I'm making no judgements on that end), but has a way --- by passing a different function --- of changing the way it rounds? The other (probably preferred) option, I suppose, would be to provide a few constants (float.FLOOR_METHOD et al.) instead of passing an arbitrary function (which, of course, makes me a bit uncomfortable). -- Cheers, Leif ___ 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
Re: [Python-Dev] trunc()
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 fit. --Guido On Jan 25, 2008 11:22 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: 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 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). 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: SQL: The INT() function returns its numeric argument with any fractional digits removed and truncates all digits to the right of the decimal point. www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm VB: Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value. http://msdn2.microsoft.com/en-us/library/xh29swte.aspx Excel: The Int function returns the integer portion of a number. http://www.techonthenet.com/excel/formulas/int.php These docs suggest where the thinking has gone wrong. Writing int(f) doesn't mean arbritrary select one of round|ceil|floor|trunc as a way of getting to an integer; instead, it means return the integer portion (non-fractional component) of a number. The latter definition seems common and is entirely unambiguous. Raymond ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
[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 to n-digits. I've taught a lot of classes to spreadsheet users and have observed that people get it right away. Raymond ___ 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
Re: [Python-Dev] trunc()
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 worth, here are MySQL's own two cents: mysql create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from t; +--+ | a| +--+ |1 | |2 | | -2 | | -1 | +--+ 4 rows in set (0.00 sec) 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. Second, that example isn't making use of the INT() function. I was going to show you result of taking the INT() of a float column containing your test values. That was when I found out that MySQL (5.0.41, anyway) doesn't implement the INT() function. What was I saying about standards? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
Re: [Python-Dev] trunc()
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 semantics -- it takes any object and converts it to an int (a concrete type!) using whatever rules it likes -- the definition of __int__ is up to whatever the source type likes to do. For float this has been defined the same as trunc() above, but for other types, who knows! int() of a string does something completely different. Perhaps worse is that sometimes int() is lossy (e.g. with a float input) and sometimes it is not (e.g. with a string input, or with a non-standard representation of integers). There are still some places where a float is accepted incorrectly (silently truncating) due to the use of the __int__ slot. If trunc() had been part of the language from the beginning we wouldn't have needed to introduce __index__. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 undefined semantics -- it takes any object and converts it to an int (a concrete type!) using whatever rules it likes -- the definition of __int__ is up to whatever the source type likes to do. For float this has been defined the same as trunc() above, but for other types, who knows! int() of a string does something completely different. But why is that a reason to keep trunc()? If you only ever want to convert floats to ints, you can use either one, with no difference. int() does *not* have undefined semantics, for floats, it converts it to an integer using round-towards-zero semantics. Regards, Martin ___ 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
Re: [Python-Dev] 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 A: ... def __trunc__(self): ... return 0 ... a=A() trunc(a) 0 However, PEP 3141 specifies what it should do for Numbers. int() has undefined semantics -- it takes any object and converts it to an int (a concrete type!) using whatever rules it likes -- the definition of __int__ is up to whatever the source type likes to do. For float this has been defined the same as trunc() above, but for other types, who knows! int() of a string does something completely different. But why is that a reason to keep trunc()? If you only ever want to convert floats to ints, you can use either one, with no difference. int() does *not* have undefined semantics, for floats, it converts it to an integer using round-towards-zero semantics. Yes (although it wasn't always specified this way). But I don't like that, because of the ambiguity of int(x). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] trunc()
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 tiny wrapper around the system's libm. Functions for magic hooks like __trunc__ usually end up in builtins. In this particular case I don't mind where the function is going to live. Christian ___ 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
Re: [Python-Dev] trunc()
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 concrete type!) using whatever rules it likes -- the definition of __int__ is up to whatever the source type likes to do. What are the use-cases for when trunc() vs int() should be used, and for when a class should define __trunc__ vs __int__? This might help clear up whether both deserve to be a built-in, as well provide a starting point for 3.0 best practices. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ 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
Re: [Python-Dev] trunc()
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 undefined semantics -- it takes any object and converts it to an int (a concrete type!) using whatever rules it likes -- the definition of __int__ is up to whatever the source type likes to do. What are the use-cases for when trunc() vs int() should be used, and for when a class should define __trunc__ vs __int__? If you intend to convert a real number (usually float, since Decimal has decided not to support it) to an Integral (usually int), use whichever of trunc(), round(), math.floor(), or math.ceil() you intend. In 2.6, that list only includes trunc(). If you absolutely need an int (the concrete, not duck type) from an Integral or you want to parse a string, use int(). Real numbers should define __trunc__. Integrals and, perhaps, some string-like types (maybe an MD5 class?) should define __int__. At least, that's my suggestion. -- 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
Re: [Python-Dev] trunc()
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 similar signatures in the same place? [Christian Heimes] Traditionally the math module is a tiny wrapper around the system's libm. Functions for magic hooks like __trunc__ usually end up in builtins. In this particular case I don't mind where the function is going to live. Traditions have gone out the window. ceil() and floor() are going to have their signatures changed (Real -- Integral) and are going to have their own magic methods. They cannot be characterized as a thin wrapper around libm. So the question stands, why is trunc() different? Can anything good come from having trunc() and int() in the same namespace? 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 implemented by float (and by decimal.Decimal) is equivalent to but less explicit than trunc(), let's remove it. (Or, if that breaks too much, just add a deprecation warning.) That needs to be updated and implemented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. 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. -- 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
