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

Inconsistent exception usage in PyLong_As* C functions #57118

Closed
nadeemvawda mannequin opened this issue Sep 6, 2011 · 11 comments
Closed

Inconsistent exception usage in PyLong_As* C functions #57118

nadeemvawda mannequin opened this issue Sep 6, 2011 · 11 comments
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@nadeemvawda
Copy link
Mannequin

nadeemvawda mannequin commented Sep 6, 2011

BPO 12909
Nosy @rhettinger, @mdickinson, @pitrou
Files
  • pylong-exceptions.diff
  • pylong-exceptions.diff
  • 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 = 'https://github.com/rhettinger'
    closed_at = <Date 2011-09-07.19:46:50.992>
    created_at = <Date 2011-09-06.07:40:15.787>
    labels = ['interpreter-core', 'type-bug']
    title = 'Inconsistent exception usage in PyLong_As* C functions'
    updated_at = <Date 2011-09-07.22:03:02.464>
    user = 'https://bugs.python.org/nadeemvawda'

    bugs.python.org fields:

    activity = <Date 2011-09-07.22:03:02.464>
    actor = 'rhettinger'
    assignee = 'rhettinger'
    closed = True
    closed_date = <Date 2011-09-07.19:46:50.992>
    closer = 'nadeem.vawda'
    components = ['Interpreter Core']
    creation = <Date 2011-09-06.07:40:15.787>
    creator = 'nadeem.vawda'
    dependencies = []
    files = ['23106', '23110']
    hgrepos = []
    issue_num = 12909
    keywords = ['patch']
    message_count = 11.0
    messages = ['143588', '143593', '143605', '143606', '143613', '143614', '143654', '143701', '143703', '143704', '143710']
    nosy_count = 5.0
    nosy_names = ['rhettinger', 'mark.dickinson', 'pitrou', 'nadeem.vawda', 'python-dev']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue12909'
    versions = ['Python 3.3']

    @nadeemvawda
    Copy link
    Mannequin Author

    nadeemvawda mannequin commented Sep 6, 2011

    The C functions for converting a Python 'int' object to a C integer are
    inconsistent about what exception gets raised when the object passed to
    them is not an integer. Most of these functions raise a TypeError, but
    PyLong_AsUnsignedLongLong() and PyLong_AsDouble() raise a SystemError
    instead.

    Raising a SystemError here is quite unhelpful. My understanding is that
    it is intended to indicate internal programming errors, so an extension
    module should not raise one when (for example) a function is passed an
    argument of the incorrect type. In such a case, raising a TypeError is a
    reasonable default.

    Is there any reason not to change the behaviour of these two functions to
    be consistent with their siblings?

    @nadeemvawda nadeemvawda mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Sep 6, 2011
    @mdickinson
    Copy link
    Member

    +1 for turning these into TypeErrors. It makes little sense that PyLong_AsLongLong and PyLong_AsUnsignedLongLong behave differently here.

    Do you have a patch handy?

    @nadeemvawda
    Copy link
    Mannequin Author

    nadeemvawda mannequin commented Sep 6, 2011

    Do you have a patch handy?

    See attached.

    @nadeemvawda
    Copy link
    Mannequin Author

    nadeemvawda mannequin commented Sep 6, 2011

    This probably shouldn't be backported to 3.2; it could break 3rd-party
    extension modules (though I would hope that nothing depends on this
    behaviour...).

    Also, it's worth noting that the error handling between conversion
    functions still isn't completely consistent - some attempt to coerce
    the argument to an integer using type->tp_as_number->nb_int, while
    others fail immediately when they see that PyLong_Check() fails.
    That's a less pressing issue, though.

    @mdickinson
    Copy link
    Member

    This probably shouldn't be backported to 3.2

    Agreed; I don't see this as a bugfix (especially since AFAIK it's not documented that TypeError should be raised here); rather, as a design improvement.

    Also, it's worth noting that the error handling between conversion
    functions still isn't completely consistent

    True; there are a number of inconsistencies left. We'll get them all eventually. :-)

    @mdickinson
    Copy link
    Member

    The patch still needs tests (e.g., in test_capi). I'm not sure whether it would be good to add information about the TypeError to the docs.

    @nadeemvawda
    Copy link
    Mannequin Author

    nadeemvawda mannequin commented Sep 6, 2011

    Attached is an updated patch with tests.

    There don't seem to be any tests for PyLong_AsS[s]ize_t() and
    PyLong_AsDouble(), so I added new ones for this issue. They should still
    be expanded on at some point in the future, but for the meanwhile this
    should be sufficient.

    I'm not sure whether it would be good to add information about the TypeError to the docs.

    Yeah, that doesn't seem necessary; raising TypeError in this sort of
    situation is sufficiently typical behavior that explicitly documenting
    it feels redundant.

    @nadeemvawda nadeemvawda mannequin self-assigned this Sep 6, 2011
    @mdickinson
    Copy link
    Member

    Looks good to me.

    I'd prefer 'test_long_as_size' to be called 'test_long_as_size_t' (even though that's inaccurate for the ssize_t bits :-).

    The 'Py_None' reference counting in test_long_as_size and test_long_as_double looked a little odd at first glance---particularly the lack of a Py_INCREF just before the return Py_None. I see that it works; it just caught my eye.

    Anyway, those are just nitpicks; I leave it to you whether you want to change anything. Otherwise, please go ahead and apply. Thanks for the patches!

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 7, 2011

    New changeset 4a66a35da3fd by Nadeem Vawda in branch 'default':
    Issue bpo-12909: Make PyLong_As* functions consistent in their use of exceptions.
    http://hg.python.org/cpython/rev/4a66a35da3fd

    @nadeemvawda
    Copy link
    Mannequin Author

    nadeemvawda mannequin commented Sep 7, 2011

    The 'Py_None' reference counting in test_long_as_size and
    test_long_as_double looked a little odd at first glance

    Indeed, it is rather roundabout, so I added a comment to avoid confusion.

    Anyway, those are just nitpicks; I leave it to you whether you want to
    change anything. Otherwise, please go ahead and apply. Thanks for the
    patches!

    Thanks for the review.

    @nadeemvawda nadeemvawda mannequin closed this as completed Sep 7, 2011
    @rhettinger
    Copy link
    Contributor

    +1

    @rhettinger rhettinger assigned rhettinger and unassigned nadeemvawda Sep 7, 2011
    @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
    interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants