On 12/29/2020 5:23 PM, Antoine Pitrou wrote:
The third option is to add a distinct "string view" protocol. There
are peculiarities (such as the fact that different objects may have
different internal representations - some utf8, some utf16...) that
make the buffer protocol suboptimal for this.
Also, we probably don't want unicode-like objects to start being usable
in contexts where a buffer-like object is required (such as writing to
a binary file, or zlib-compressing a bunch of bytes).
I've had to deal with this problem in the past as well (WinRT HSTRINGs),
and this is the approach that would seem to make the most sense to me.
Basically, reintroduce PyString_* APIs as an _abstract_ interface to
str-like objects.
So the first line of every single one can be PyUnicode_Check() followed
by calling the _concrete_ PyUnicode_* implementation. And then we
develop additional type slots or whatever is necessary for someone to
build an equivalent native object.
Most "is this a str" checks can become PyString_Check, provided all the
APIs used against the object are abstract (PyObject_* or PyString_*).
Those that are going to mess with internals will have to get special
treatment.
I don't want to make it all sound too easy, because it probably won't
be. But it should be possible to add a viable proxy layer as a set of
abstract C APIs to use instead of the concrete ones.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TC3BZJX4DGC2WV32AHIX7A57HQNJ2EMO/
Code of Conduct: http://python.org/psf/codeofconduct/
