-
Notifications
You must be signed in to change notification settings - Fork 1
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
Disallow mutating immutable objects #20
Comments
I still think this is setting the bar too high for tuple creation. |
Maybe we can make "this object is now eligible for GC" a more explicit step? We likely don't need a formal pattern everywhere, but it would be nice if native code could assume that it holds the only reference to a new object up until it returns or shares it. |
In the guidelines for future API, I'd like to say that the |
Then you should also show how you would design a tuple builder today. It should have all the features of the existing tuple construction API (including resizing). Hopefully it would be more ergonomic than the current approach. |
Probably like this:
(In today's API we'd use There is an explicit "this object is now eligible for GC" step, which creates a |
What API should be used to actually set item There are two exit paths, mutually exclusive, right? You end with either The naming could use some work. This pattern might be reused widely if we get it right. |
It'd be a |
In most cases It's only in the rare cases that you are building tuples with runtime-varying sizes that you need a way to populate the contents iteratively. And you could also expose a new API such as: PyObject *PyTuple_PackArray(Py_ssize_t n, PyObject** items); |
|
My draft avoids a memcpy; with inlining it should be as fast as the current approach. I assume CPython core and Cython will want that. But yes, |
From Mark's proposal
New API should not mutate immutable objects. The biggest offenders are currently:
char*
)The text was updated successfully, but these errors were encountered: