Deprecating the direct use of str internals, e.g. PyASCIIObject, PyCompactUnicodeObject, PyUnicodeObject structs

[malemburg (Marc-André Lemburg)]

Hi Petr, I’m mostly offline this week, so will likely only reply next week.

[ronaldoussoren]

@encukou

    .m_name = "mymod",
    .m_slots = (PyModuleDef_Slot[]) {
        {Py_mod_exec, mymod_exec},
        {0}  /* sentinel */
    },
};

PyObject *
PyInit_mymod(void) {
    return PyModuleDef_Init(&mymod_def);
}

This of course ignores a lot of complications, but, most are orthogonal.

AFAICS, PyObjC would want a bit of new API: PyUnicode_NewSubtype, a function like PyUnicode_New that additionally takes a “type” argument, and returns an uninitialized string that’s “fillable” with the same caveats as PyUnicode_New.

I have a draft (!) branch adding that, with a test type that exercises some of the complications.

I didn’t get PyObjC tests to run yet, I didn’t try porting NumPy, I didn’t audit the edge cases, but so far this seems viable.

That could work.

For PyObjC I’d prefer a new API that creates the subtype instance from a UTF-8 buffer (a variant on PyUnicode_FromStringAndSize), that way I’d be isolated from changes in the representation of strings.

[encukou (Petr Viktorin)]

Hi,
I am on paternity leave and will likely reply in a month.

(Ha! How’s that for a one-up?)