[issue29730] unoptimal calls to PyNumber_Check

Serhiy Storchaka added the comment: New changeset 004251059b9c5e48d47cb30b94bcb92cb44d3adf by Serhiy Storchaka (Oren Milman) in branch 'master': bpo-29730: replace some calls to PyNumber_Check and improve some error messages (#650)

[issue29730] unoptimal calls to PyNumber_Check

Oren Milman added the comment: thanks for the reviews :) -- ___ Python tracker ___ ___ Python-bugs-list

[issue29730] unoptimal calls to PyNumber_Check

Serhiy Storchaka added the comment: LGTM. Thank you Oren. -- assignee: -> serhiy.storchaka resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue29730] unoptimal calls to PyNumber_Check

Oren Milman added the comment: I am sorry, but I guess I am missing something about startswith() and endswith(). ISTM that PyTuple_Check() is already called by unicode_startswith, unicode_endswith and _Py_bytes_tailmatch, which already raise a TypeError with an appropriate error message (e.g.

[issue29730] unoptimal calls to PyNumber_Check

Changes by Oren Milman : -- pull_requests: +537 ___ Python tracker ___ ___ Python-bugs-list

[issue29730] unoptimal calls to PyNumber_Check

Serhiy Storchaka added the comment: Please open a PR for review. Checking PyTuple_Check() is needed if this code is used in startswith() and endswith(). "integer argument or None expected" -- I'm not sure this wording is correct enough. What wording is used in other similar code? I'm sure

[issue29730] unoptimal calls to PyNumber_Check

Oren Milman added the comment: "Perhaps some methods need to check also PyTuple_Check()." which methods? anyway, a new patch diff file is attached, according to your other seggustions, Serhiy. (I ran the test module, and some tests of my own, and it seems that the patch doesn't break anything.)

[issue29730] unoptimal calls to PyNumber_Check

Serhiy Storchaka added the comment: The call of PyNumber_Check() is redundant if we don't bother about error message. But if we want to have accurate error message we should check types before converting. In parse_args_finds_byte we should check rather PyObject_CheckBuffer() (and maybe

[issue29730] unoptimal calls to PyNumber_Check

Oren Milman added the comment: "In bytes/bytearray methods -- integers and bytes-like objects." (I guess you refer to parse_args_finds_byte (in Objects/bytes_methods.c)) so you suggest that in case (!PyIndex_Check(tmp_subobj)), we also check whether (PyByteArray_Check(tmp_subobj) or

[issue29730] unoptimal calls to PyNumber_Check

Serhiy Storchaka added the comment: I think it would be better to replace PyNumber_Check() with PyIndex_Check() and change error messages to more specific. In IO related functions the accepted values are integers and None. In bytes/bytearray methods -- integers and bytes-like objects.

[issue29730] unoptimal calls to PyNumber_Check

Changes by Oren Milman : -- pull_requests: +510 ___ Python tracker ___ ___ Python-bugs-list

[issue29730] unoptimal calls to PyNumber_Check

Oren Milman added the comment: after some closer examination, ISTM that in Objects/exceptions.c, we can't remove PyNumber_Check to optimize or simplify the code, as the argument 'filename' can be either an integer type (only in case the error is a BlockingIOError), or quite anything else, except

[issue29730] unoptimal calls to PyNumber_Check

Changes by Serhiy Storchaka : -- nosy: +mark.dickinson, serhiy.storchaka ___ Python tracker ___

[issue29730] unoptimal calls to PyNumber_Check

Raymond Hettinger added the comment: +1 for removing each of these calls to PyNumber_Check. -- nosy: +rhettinger ___ Python tracker ___

[issue29730] unoptimal calls to PyNumber_Check

New submission from Oren Milman: current state if (PyNumber_Check(obj)) { someVar = PyNumber_AsSsize_t(obj, SomeError); if (someVar == -1 && PyErr_Occurred()) { return errVal; } } else { PyErr_Format(PyExc_TypeError, "integer