[Python-Dev] trunc() (original) (raw)
Jeffrey Yasskin jyasskin at gmail.com
Fri Jan 25 18:24:07 CET 2008
- Previous message: [Python-Dev] trunc()
- Next message: [Python-Dev] trunc()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jan 25, 2008 5:53 AM, Paul Moore <p.f.moore at gmail.com> wrote:
On 24/01/2008, Jeffrey Yasskin <jyasskin at gmail.com> 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
- Previous message: [Python-Dev] trunc()
- Next message: [Python-Dev] trunc()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]