Skip to content
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion stringdtype/stringdtype/src/dtype.c
Original file line number Diff line number Diff line change
Expand Up @@ -146,20 +146,34 @@ static PyObject *
stringdtype_getitem(StringDTypeObject *NPY_UNUSED(descr), char **dataptr)
{
char *data;
size_t len;

if (*dataptr == NULL) {
data = "\0";
len = 0;
}
else {
data = ((ss *)dataptr)->buf;
len = ((ss *)dataptr)->len;
}

PyObject *val_obj = PyUnicode_FromString(data);
PyObject *val_obj = PyUnicode_FromStringAndSize(data, len);

if (val_obj == NULL) {
return NULL;
}

/*
* In principle we should return a StringScalar instance here, but
* creating a StringScalar via PyObject_CallFunctionObjArgs has
* approximately 4 times as much overhead than just returning a str
* here. This is due to Python overhead as well as copying the string
* buffer from val_obj to the StringScalar we'd like to return. In
* principle we could avoid this by making a C function like
* PyUnicode_FromStringAndSize that fills a StringScalar instead of a
* str. For now (4-11-23) we are punting on that with the expectation that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* str. For now (4-11-23) we are punting on that with the expectation that
* str. For now (2023-04-11) we are punting on that with the expectation that

just joking, but ISO dates all the way!

This is half-way at the place where str is the scalar. But lets try how it goes!

* eventually the scalar type for this dtype will be str.
*/
return val_obj;
}

Expand Down