Skip to content
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

Add input types to chrono type casters #931

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tjstum
Copy link
Contributor

@tjstum tjstum commented Feb 13, 2025

The type casters in stl/chrono.h accept various types in their
from_python calls, but they currently just use a name for their
output type.

This uses io_name to differentiate, adding the various acceptable
types that the casters permit at runtime

This also includes type stub testing for the test_chrono_ext module. The
first commit in this PR contains the stubs only.

@tjstum
Copy link
Contributor Author

tjstum commented Feb 13, 2025

I now understand why there aren't stubs for these functions. :-)

Is there a straightforward way to tell stubgen to emit the module attribute value as = ... in the stubs (instead of as = True or = False)? It seems like, in general, we would always want that (since the runtime value isn't relevant: just the type). I could make that change as a separate PR.

Failing that, I can reduce this PR to just the type caster change and then just leave this early version as "proof" of its correctness.

@tjstum
Copy link
Contributor Author

tjstum commented Feb 25, 2025

I've reduced the PR to just the type caster change. Hopefully this is amenable!

The type casters in `stl/chrono.h` accept various types in their
`from_python` calls, but they currently just use a name for their
output type.

This uses `io_name` to differentiate, adding the various acceptable
types that the casters permit at runtime
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.

3 participants