Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make int() fall back to trunc() #46286

Closed
jyasskin mannequin opened this issue Feb 2, 2008 · 7 comments
Closed

Make int() fall back to trunc() #46286

jyasskin mannequin opened this issue Feb 2, 2008 · 7 comments
Labels
type-bug An unexpected behavior, bug, or error

Comments

@jyasskin
Copy link
Mannequin

jyasskin mannequin commented Feb 2, 2008

BPO 2002
Nosy @gvanrossum, @rhettinger
Files
  • int_fall_back_to_trunc.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2008-02-04.01:05:29.101>
    created_at = <Date 2008-02-02.23:44:51.909>
    labels = ['type-bug']
    title = 'Make int() fall back to trunc()'
    updated_at = <Date 2008-02-04.01:05:29.100>
    user = 'https://bugs.python.org/jyasskin'

    bugs.python.org fields:

    activity = <Date 2008-02-04.01:05:29.100>
    actor = 'jyasskin'
    assignee = 'jyasskin'
    closed = True
    closed_date = <Date 2008-02-04.01:05:29.101>
    closer = 'jyasskin'
    components = []
    creation = <Date 2008-02-02.23:44:51.909>
    creator = 'jyasskin'
    dependencies = []
    files = ['9352']
    hgrepos = []
    issue_num = 2002
    keywords = ['patch']
    message_count = 7.0
    messages = ['62014', '62019', '62020', '62024', '62030', '62031', '62032']
    nosy_count = 3.0
    nosy_names = ['gvanrossum', 'rhettinger', 'jyasskin']
    pr_nums = []
    priority = 'high'
    resolution = 'accepted'
    stage = None
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue2002'
    versions = ['Python 2.6', 'Python 3.0']

    @jyasskin
    Copy link
    Mannequin Author

    jyasskin mannequin commented Feb 2, 2008

    @jyasskin jyasskin mannequin self-assigned this Feb 2, 2008
    @jyasskin jyasskin mannequin added the type-bug An unexpected behavior, bug, or error label Feb 2, 2008
    @jyasskin
    Copy link
    Mannequin Author

    jyasskin mannequin commented Feb 3, 2008

    Here's a patch to implement the fallback for both int and long. I'm
    pretty sure that _PyNumber_ConvertIntegralToInt() is in the wrong place.
    Where would be a better place for it?

    @rhettinger
    Copy link
    Contributor

    Guido, are these basically the mechanics you intended? All calls to
    PyNumber_Int() and PyNumber_Long() attempt the usual path and if those
    would fail, it tries __trunc__ if it exists and coerces the result of
    that call back to an int or long.

    The logic looks basically correct, but I'm not sure what it buys us
    since the returned Integral has to be converted back to an int or long
    anyway. On the plus side, it does not slow down the common case where
    PyNumber_Int() and PyNumberLong() would ordinarily succeed.

    An alternative to this patch would be to have math.trunc() try to
    return __trunc__() and if it doesn't exist, fallback to __int__. That
    avoids having arbitrary Integrals forced back into ints/longs, but it
    may not be what you guys were after.

    Either way will allow a user to define a __trunc__() method and have
    math.trunc() return an arbitrary Integral, not necessarily and int or
    long.

    There is also part of this patch that touches classobject.c but I'm not
    yet sure what the visible effect of that change would be or what the
    change was hoping to accomplish.

    @rhettinger rhettinger assigned gvanrossum and unassigned jyasskin Feb 3, 2008
    @jyasskin
    Copy link
    Mannequin Author

    jyasskin mannequin commented Feb 3, 2008

    There is also part of this patch that touches classobject.c but I'm not
    yet sure what the visible effect of that change would be or what the
    change was hoping to accomplish.

    All classic classes take the (m && m->nb_int) branch, so without the
    change to classobject.c, they'd never hit the fallback to __trunc__.
    The unfortunate side-effect is that when you call int() or long() on a
    classic class without the right methods, you get an AttributeError
    complaining about __trunc__ instead of about __int__. Since long()
    already mistakenly complained about __int__, I didn't consider this a
    showstopper, but it should be possible to fix if you want.

    @gvanrossum
    Copy link
    Member

    Guido, are these basically the mechanics you intended? All calls to
    PyNumber_Int() and PyNumber_Long() attempt the usual path and if those
    would fail, it tries __trunc__ if it exists and coerces the result of
    that call back to an int or long.

    Yes, that's exactly what I suggested.

    The logic looks basically correct, but I'm not sure what it buys us
    since the returned Integral has to be converted back to an int or long
    anyway.

    Unless it's already an int or long. I would expect a type that wants
    to play along with the ABCs defined in numbers.py will define
    __trunc__ and not __int__ (since the latter isn't part of the ABC) but
    it would have to be a pretty esoteric type not to return an int or
    long.

    On the plus side, it does not slow down the common case where
    PyNumber_Int() and PyNumberLong() would ordinarily succeed.

    Great -- so no penalty for builtin types.

    An alternative to this patch would be to have math.trunc() try to
    return __trunc__() and if it doesn't exist, fallback to __int__. That
    avoids having arbitrary Integrals forced back into ints/longs, but it
    may not be what you guys were after.

    Definitely not -- that would imply that math.trunc("42") would return
    the integer 42!

    Either way will allow a user to define a __trunc__() method and have
    math.trunc() return an arbitrary Integral, not necessarily and int or
    long.

    Correct, and that's as intended.

    There is also part of this patch that touches classobject.c but I'm not
    yet sure what the visible effect of that change would be or what the
    change was hoping to accomplish.

    Looks like Jeffrey expained that already.

    @rhettinger
    Copy link
    Contributor

    Go for it.

    @rhettinger rhettinger assigned jyasskin and unassigned gvanrossum Feb 4, 2008
    @jyasskin
    Copy link
    Mannequin Author

    jyasskin mannequin commented Feb 4, 2008

    Submitted as r60566.

    @jyasskin jyasskin mannequin closed this as completed Feb 4, 2008
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants