-
-
Notifications
You must be signed in to change notification settings - Fork 11.9k
MAINT, BUG: Remove uses of PyString_FromString. #17068
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
MAINT, BUG: Remove uses of PyString_FromString. #17068
Conversation
4ed2384 to
9915e28
Compare
|
Apologies @charris, I thought I was reviewing code from @jakobjakobson13! Identicons are apparently too similar at the end of the day. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, if this is auto-generated then maybe we should not be editing it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in the repo, doesn't go away with git clean -xdfq and the content dates back to 2005. I think the string is intended for code generated by wrapper.c. However, in that case it is probably best to keep the message in bytes... It is a docstring for modules using wrapper.c and is directly set during module init. The tests pass with it as patched.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the string is intended for code generated by
I think you're right, but the top of this file also says its autogenerated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably just left over from before the tests were redone. Note that it is only used in setting up test_array_from_pyobj.py, so I think it really doesn't matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wrapmodule.c is used in numpy/f2py/tests/test_array_from_pyobj.py and can be considered constant, that is, it can be manually modified.
For background: he file was generated with f2py as a C/API module template and later modified manually to expose various macro constants to Python for testing..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like that part of the header can just be removed. I'll leave this PR as is with a release note and make a separate PR with the version changes and other small cleanups suggested here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you like to wait for this to be merged until the follow-on PR is made?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand your question @mattip, the header is changed already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattip No :) I'm waiting for this to be merged. The follow-on PR just changes the version handling.
9915e28 to
90d644c
Compare
|
It's tempting to split this into two phases:
|
I agree that we need to replace all the compat functions, but would rather do it in smaller pieces. Look how much work this small bit is already taking :) I think blind replacement just makes it harder to find the uses that may need fixing. |
|
Right now, I am still happy to keep it here, since its not time pressing to do the replacement and the PR is not big. The remaining issue is mainly the I suppose for some of the things that end up being fixes, including a test might be nice (also helps with judging whether anything should have release notes), but not sure. |
|
I just noticed this PR and I'd like to review the f2py bits. However, it's late here but I can review tomorrow. |
pearu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM from the f2py point of view.
While slightly OT, added some suggestions for updating f2py version handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wrapmodule.c is used in numpy/f2py/tests/test_array_from_pyobj.py and can be considered constant, that is, it can be manually modified.
For background: he file was generated with f2py as a C/API module template and later modified manually to expose various macro constants to Python for testing..
|
Think it's worth adding a test for the code snippets I give above that expose what this fixed? At any rate, this should be |
We no longer need to use the compatibility function after dropping support for Python 2.7. In some cases unicode was the correct string type rather than the bytes of the compatibility version and bugs in the array `__complex__` and array `__array_interface__` methods have been fixed by changing that.
90d644c to
8c226bf
Compare
Been thinking about that. We could add those to the regressions checks, but in the long run it would be useful to figure out how to generate a set of comprehensive tests for both errors and descriptors. @seberg may have some ideas about the latter. |
4d4bacc to
36da1b2
Compare
- Invalid conversion error bug. - ``__array_interface__['descr']`` bug
36da1b2 to
434d2f1
Compare
eric-wieser
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the tests. I think with @pearu's review of the f2py stuff, this is now good to go.
|
I was asking generally about this PR: there are follow-on cleanups:
I guess we should merge this now and then submit a follow-on PR. In it goes. |
|
Thanks @charris |
We no longer need to use the compatibility function after dropping support for
Python 2.7. In some cases unicode was the correct string type rather than the
bytes of the compatibility version and bugs in the array
__complex__andarray
__array_interface__methods have been fixed by changing that.