Skip to content

Conversation

@davidhewitt
Copy link
Member

This is a proposal to make a first step towards resolving #5245

The idea is to add PyUntypedBuffer, which is a sibling to PyBuffer<T> which does not care about the actual element type it holds inside. I got the idea of the name from PyUntypedArray in rust-numpy.

I can imagine that this is potentially applicable in a number of cases where the user wants to attempt to get a buffer export from an object but doesn't necessarily know what element type the object will export. PyUntypedBuffer::get() can be used to get the export, .format() can then be inspected to deduce what concrete element T to cast the buffer to.

I think while we're here I moved a lot of the implementations of methods from PyBuffer<T> to PyUntypedBuffer, which may slightly reduce generic code bloat.

@davidhewitt
Copy link
Member Author

davidhewitt commented Jan 18, 2026

Is anyone interested in reviewing this? If not, I am tempted to merge this soon to move this and #5245 forward.

src/buffer.rs Outdated
#[inline]
pub fn buf_ptr(&self) -> *mut c_void {
self.raw().buf
self.0.buf_ptr()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do not necessarily need to have these forwarding methods. They should be available via Deref directly from the underlying PyUntypedBuffer. It would be a breaking change however because fully qualified syntax would change,

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, and I'm open to not having them. I added exactly to avoid breaking fully-qualified syntax, though I don't know how much that'll really be used in practice.

If we removed, I guess we could just nod to this change in the migration guide.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I would not expect it to be a problem in practice. Outside of macros fully-qualified syntax is rarely used and migrating would be trivial anyway. I think I would remove them, but I don't feel super strong about that and you can also decide to keep if you prefer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed these, we can restore them if we have complaints.

@davidhewitt davidhewitt enabled auto-merge January 19, 2026 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants