fixes for StringDType #22
Conversation
|
Honestly, now that I see arbitrary sized strings passing length seems weird. For most functions, the long-term thing would be a ufunc replacement. For others, I suppose we have no good story, we could hide something away like Anyway, don't want to derail trials here, just seems like something better is needed if we really want full support for something like |
| { | ||
| PyObject *ret_bytes = NULL; | ||
| PyTypeObject *scalar_type = Py_TYPE(scalar); | ||
| // FIXME: handle bytes too |
There was a problem hiding this comment.
Maybe numpy bytes only? Normal bytes shouldn't be necessary, Python 3 doesn't do it. NumPy bytes are just weird because they serve the dual purpose of an ascii/latin1 string.
|
Agreed that passing a size is weird. I'd like to come back to that, I agree that it might be better to just expose all the functionality in |
| "common_instance called on unequal StringDType instances"); | ||
| return NULL; | ||
| } | ||
| Py_INCREF(dtype1); |
stringdtype/stringdtype/src/dtype.c
Outdated
|
|
||
| long size = 0; | ||
|
|
||
| if (!PyArg_ParseTupleAndKeywords(args, kwds, "|l:ASCIIDType", kwargs_strs, |
There was a problem hiding this comment.
| if (!PyArg_ParseTupleAndKeywords(args, kwds, "|l:ASCIIDType", kwargs_strs, | |
| if (!PyArg_ParseTupleAndKeywords(args, kwds, "|l:StringDType", kwargs_strs, |
ngoldbaum
force-pushed
the
string-dtype-fixes
branch
from
ab6ef04 to
865c973
Compare
This brings over some functionality from
asciidtype. I also include someasciidtypechanges here to keepstringdtypeandasciidtypemore uniform.StringScalarastrsubclass. This makes it possible to use the functions innp.charto manipulateStringDTypedatapartitionandrpartitionwrappers to make sure the result of those functions has uniform types.common_instance. Also simplifies it a bit sinceStringDTypeisn't parametric.StringDTypewith an optionalsizeargument, which gets ignored. This makes the API more uniform with numpy's other string dtypes. In particular, this way of creating a string dtype is now used innp.char, so this also allowsStringDTypeto work with functions innp.char. Currently we just ignore thesizebut in principle we could use it as a size hint? I'm not sure if that's actually useful.