🌐 AI搜索 & 代理 主页
Skip to content

Conversation

@youknowone
Copy link
Member

I am considering new subclass payload layout to provide

  1. Actually subclass typed function parameters, like using PyRef instead PyRef
  2. adding new fields to the subclass payload, which cause error right now.

I will left open questions on the code.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 2, 2025

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Comment on lines 92 to 94
#[inline]
fn payload_type_id() -> std::any::TypeId {
std::any::TypeId::of::<PyInt>()
}
Copy link
Member Author

@youknowone youknowone Dec 2, 2025

Choose a reason for hiding this comment

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

This is okay here, because PyInt and PyBool shares same payload. The only difference is type.

But implementing this makes PyPayload::downcastable to be automatically true for any kind of PyInt. It doesn't make failing tests on this patch because we don't use that pattern. But it obviously will be a sort of trap for future developing.

Another question is that PyPayload::downcastable only takes &PyObject currently. We can't compare it to actual type... because we don't have vm.ctx.

#[pyclass(name = "bool", module = false, base = PyInt)]
pub struct PyBool;
#[repr(transparent)]
pub struct PyBool(pub PyInt);
Copy link
Member Author

Choose a reason for hiding this comment

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

Now we have to manually define the base layout to be always leading field.
The problem is Rust actually only guarantees it to be actually same layout only when #[repr(transparent)] is used.

What I didn't check yet: Can using #[repr(C)] helps? Is there any other repr options to keep the first field as same as its original layout?

@youknowone youknowone force-pushed the new-subclass branch 2 times, most recently from e312bbf to 8db2660 Compare December 2, 2025 05:20
Copy link
Collaborator

@ShaharNaveh ShaharNaveh left a comment

Choose a reason for hiding this comment

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

Looks super cool. I am a bit worried that we are not actually using it anywhere ATM so we can't validate that it's not a breaking change.

How difficult would it be to gradually transition to pattern?

@youknowone youknowone force-pushed the new-subclass branch 2 times, most recently from afe436d to 4e2edcc Compare December 2, 2025 12:21

#[inline]
fn validate_downcastable_from(obj: &::rustpython_vm::PyObject) -> bool {
<Self as ::rustpython_vm::class::PyClassDef>::BASICSIZE <= obj.class().slots.basicsize && obj.class().fast_issubclass(<Self as ::rustpython_vm::class::StaticType>::static_type())
Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe I found another way to do with more tricks. Let's check it with OSError

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