-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Argument Clinic: add unsigned integers converters #64459
Comments
Proposed patch adds support for non-bitwise unsigned integer arguments in Argument Clinic. I.e. now unsigned_int(bitwise=False) (or just unsigned_int) converts Python int in range from 0 to UINT_MAX to C unsigned int. Added support for unsigned_short, unsigned_int, unsigned_long, unsigned_PY_LONG_LONG, and size_t. Also added global private functions _Py_UnsignedShort_Converter(), _Py_UnsignedInt_Converter(), _Py_UnsignedLong_Converter(), _Py_UnsignedLongLong_Converter(), and _Py_Size_t_Converter(), which are used by Argument Clinic and in C code still not converted to Argument Clinic. |
Very nice! I had an idea to do this in the back of my head too. But my plate is already full. I haven't reviewed the patch yet--and I have a huge backlog of reviews already. But I can give this higher priority if you need it for other patches. When do you need this reviewed? |
Currently these converters are used only in zlib (unsigned int) and select (unsigned short). But perhaps during conversion to Argument Clinic we will discover that they are more appropriate than bitwise converters in other places. So there is no hurry. |
We can use this now. So I bumped it to the top of my queue and reviewed it. I had only minor feedback--thanks! |
Unfortunately I have discovered that there is significant difference between uint_converter in Modules/zlibmodule.c and proposed _PyLong_UnsignedInt_Converter. And there are tests in Lib/test/test_zlib.py which fail when _PyLong_UnsignedInt_Converter is used instead of uint_converter. uint_converter raises ValueError for negative integers, and _PyLong_UnsignedInt_Converter raises OverflowError. Possible solutions:
Here is a patch which incorporates Larry's suggestions and implements option #3. |
Oh, and of course 5th option: do nothing. |
I think we cannot change PyLong_AsUnsignedLong() without a deprecation period, My preference is to raise either OverflowError or ValueError for *both* People may me used to OverflowError by now -- the usage in PyLong_AsUnsignedLong() |
I'm glad you caught that! First things first: the converted code should behave identically to the existing code, including raising the same exceptions. If you examine the exception hierarchy: you'll see that "OverflowError" is a subclass of "ArithmeticError". In other words, it represents when you perform an arithmetic operation that overflows the result type. Using it to also represent "you specified a value that is out of range for this conversion" seems wrong. So I like #3 as well. Could _PyLong_UnsignedInt_Converter catch the OverflowError raised by PyLong_AsUnsignedLong and reraise it as ValueError? |
socketmodule has three builtins which use PyLong_AsUnsignedLong on their arguments and would benefit from these converters, but only if they raise OverflowError. So I vote for #2. I don't think it's unreasonable to continue to have locally-defined argument converters. |
Is this waiting on something? I agree that we can't change the behavior |
Also, you didn't remove the _ in front of "Converter" in the names, e.g "_PyLong_UnsignedShort_Converter" should be "_PyLong_UnsignedShortConverter". |
Actually, here's another data point to consider. The underlying implementation of PyArg_Parse* is the function convertsimple() in Python/getargs.c. For all the non-bitwise integer format units ('bhi'), if they overflow or underflow the native integer they raise OverflowError. |
I think that we do not yet have enough data. Too little cases are known for which unsigned integer converters are needed, and different cases require a different behavior. I prefer to defer until we convert the majority of the code. Then we will see what behavior is most prevalent. We even can change and unify behavior in 3.5. There is no hurry. We can use in each module its own Converter (if needed). There should not be many such places. |
I can start citing data points if you like. socket.if_indextoname just calls PyLong_AsUnsignedLong(). Not sure what that throws. |
… Clinic. (python/cpython#8434) GitHub-Issue-Link: python/cpython#64459
… Clinic. (python/cpython#8434) GitHub-Issue-Link: python/cpython#64459
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: