gh-119182: Add PyUnicodeWriter C API #119184
Conversation
- Issue: [C API] Add an efficient public PyUnicodeWriter API #119182
8de16a1 to
4d18300
Compare
4d18300 to
308d608
Compare
49a46ac to
14e739b
Compare
14e739b to
fd7432e
Compare
Remove PyUnicodeWriter_SetOverallocate().
fd7432e to
b12f085
Compare
|
@erlend-aasland @serhiy-storchaka @encukou: Do you want to review this change? |
| *str* must be Python :class:`str` object. *start* must be greater than or | ||
| equal to 0, and less than or equal to *end*. *end* must be less than or | ||
| equal to *str* length. |
There was a problem hiding this comment.
Nit; I prefer to use SemBr for paragraphs like this.
| *str* must be Python :class:`str` object. *start* must be greater than or | |
| equal to 0, and less than or equal to *end*. *end* must be less than or | |
| equal to *str* length. | |
| *str* must be Python :class:`str` object. | |
| *start* must be greater than or equal to 0, | |
| and less than or equal to *end*. | |
| *end* must be less than or equal to *str* length. |
There was a problem hiding this comment.
TIL that this is called SemBr!
Breaking on comma may be too much, but I prefer to break at the sentence boundary.
There was a problem hiding this comment.
Yeah. You don't need to break at comma, but I often do to minimise future diffs.
Alternative suggestion:
| *str* must be Python :class:`str` object. *start* must be greater than or | |
| equal to 0, and less than or equal to *end*. *end* must be less than or | |
| equal to *str* length. | |
| *str* must be Python :class:`str` object. | |
| *start* must be greater than or equal to 0, and less than or equal to *end*. | |
| *end* must be less than or equal to *str* length. |
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
|
@erlend-aasland: I addressed your review. Would you mind to review the updated PR? |
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
I did nothing to make them safe, so I would say that they are not thread safe. You must not share a writer between two threads. Use one writer per thread. |
|
@malemburg @serhiy-storchaka: I modified the implementation to make write operations atomic. Either the whole string is written, or "nothing is written". In the doc, I wrote "On error, leave the writer unchanged". In practice, it's more subtle, the internal buffer can be enlarged, or its kind (UCS1, UCS2 or UCS4) can change. But from the API consumer point of view, it's as if nothing was written. I added two unit tests to show that it's still possible to use a writer after an error. The hack is just to save/restore |
I withdraw my approve because writing cannot be atomic.
| @@ -13408,6 +13546,17 @@ _PyUnicodeWriter_Finish(_PyUnicodeWriter *writer) | |||
| return unicode_result(str); | |||
| } | |||
|
|
|||
|
|
|||
| PyObject* | |||
There was a problem hiding this comment.
Nit: inconsistent with the rest of the PR.
| PyObject* | |
| PyObject * |
|
@picnixz: I appreciate your remarks about coding style, but IMO you're going too far. I marked your "two empty lines" suggestions as resolved. This PR is already approved, twice. It's a complex API being discussed for 1 month and I would prefer to not waste my time on coding style. However, I fixed the "an Unicode" typos, thanks :-) |
|
The C API Working Group agreed to start with this minimum PyUnicodeWriter API. I merged my PR. |