ENH: Added new ability to doc ufuncs #134
Conversation
|
|
||
| docstr = PyBytes_AS_STRING(PyUnicode_AsUTF8String(str)); | ||
| #else | ||
| if (!PyArg_ParseTuple(args, "O!O!", &PyUFunc_Type, &ufunc, |
There was a problem hiding this comment.
The argument parsing can be moved out of the #if...#endif section.
|
Looks generally good. The C coding style needs some cleanup and the tests seem a bit skimpy, although without having a test ufunc it is difficult to see what else can be done. Any thoughts about using this for the current ufunc docstrings? |
|
Nope, no real thoughts about using it for the current ufunc docstrings. I wasn't completely comfortable with this function, since it does technically introduce a memory leak. If you think making that change would be a good idea, then I'm happy to do it. I agree about the test. I would have added a test, but to do so would require a dummy ufunc. And the two options for that would seem to be inserting a dummy ufunc into numpy itself (weird) or making a .c file and setup.py file to create a .so file for a ufunc in the test file. But that would also be weird. Given two weird options I wasn't sure which to use, so I just did neither. If you can recommend a course of action I'd happily add a test(s). |
|
Changes made and pushed. |
|
This needs to be rebased on master, the ufunc_object.c file has changed. Mostly you just need to replace self by ufunc in your modifications. |
|
Ok, rebased. I think. All I did was change the self to ufunc, since that seemed to be the only conflict. |
|
Pushed in 180750b. You might want to test it. |
feat: Add vqrshrn_n_s16
Currently the only way to add docstrings to ufuncs is at their time of creation. This is because the doc's for a ufunc are read-only. (Apparently this is true of all new-style objects in python.) In particular add_newdoc doesn't work on ufuncs.
This is an implementation of a solution Mark Wiebe suggested. It's simply changes the pointer for doc in the ufunc so it points to a new string. It can only be used when the ufunc is intialized with doc pointing to NULLL. (The ufunc creation function was changed so that if NULL was passed to doc then self->doc is set to NULL rather than "NULL".) Technically it introduces a memory leak as the new docstring will not have its memory freed even if the ufunc is thrown away. But that possibility seems quite unlikely as a use case.
I also added a note for the unwary in the numpy.core ufunc creation docs. The syntax there makes it look like add_newdoc is being used, but it isn't. The docstrings are placed in a dictionary that is then imported to the ufunc code generator where the docstrings can be passed down to the C level when the ufuncs are created. This gives the false impression that add_newdoc does work for ufuncs. (This false impression is further reinforced by add_newdoc not throwing errors if it can't change the docstring of its argument.)