-
-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for Comments: Added UnicodeBuilder #205
base: master
Are you sure you want to change the base?
Conversation
e11a645
to
914b447
Compare
The idea turned out to be very closely related to HPyTracker, so I blatantly stole some code there.
914b447
to
cd4c539
Compare
@cklein Thank you for starting this (its really great to have code to look at to kick-off the design discussion). Apologies for taking a bit long to reply -- life got in the way for awhile. My 2c on the API design: I think we want an API that works more with C strings than HPy handles that point to strings. For me the important use case is "I'm trying to efficiently construct a Python string from a possibly unknown number of C strings". That's currently hard in HPy because unlike in the old C API, we don't want to expose the raw character buffer because that constrains the Python implementation to store strings in that format. In particular, it would be good to be able to use UnicodeBuilder when implementing I think the structure of the current PR is pretty good though, and perhaps we can fulfill the above needs with just a few changes to the API:
Then the buffer management is all hidden behind the API and |
Thanks a lot for the feedback @hodgestar. There are some open questions:
|
68df196
to
74e2eef
Compare
74e2eef
to
c2ed4f2
Compare
@cklein sorry for the very late response. Some part of the delay was caused by real-life issues, but a good part of it was because I spent a lot of time trying to think of the appropriate API that we want for |
RfC
This is a very early draft for an implementation of UnicodeBuilder.
As @antocuni pointed out in cklein#1, a having a discussion around the API first is a good idea, so take the implementation details with a grain of salt and have a focus on the API.
Maybe it's easier to have a discussion on #181 first.
The first iteration (first commit) was very close to ListBuilder and TupleBuilder although it seemed to make sense to preallocate memory.
This changed in the second iteration and it turned out to be a lot like HPyTracker, so it took over some naming conventions.
One of the main differenes is that it uses a C-Python list under the hood to store objects.
Currently there's no way to add objects beyond the initial capacity.
If this is continuing to use a C-Python list, the implementation could switch back from PyList_SET_ITEM to PyList_Append
which automatically handles reallocation including overallocation.
Or the storage could be setup similar to HPy_Tracker and share the reallocation strategy.
A third option would be to internally use a HPy_Tracker, it already provides everything that's needed.