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

Extending native types doesn't work as expected #184

Open
pschanely opened this issue Nov 11, 2022 · 2 comments
Open

Extending native types doesn't work as expected #184

pschanely opened this issue Nov 11, 2022 · 2 comments

Comments

@pschanely
Copy link
Owner

As shown in this example, extending native types (that CrossHair cares about) doesn't work as expected.

I suspect there may be multiple layers of problems, the first of which is that a correct constructor signature is harder to deduce for these types.

cc @mristin

@mristin
Copy link
Contributor

mristin commented Nov 11, 2022

@pschanely thanks! Be aware that we used __new__ intensively to impose constraints on primitive types in https://github.com/mristin/python-by-contract. That was a "canonical" way for me, and also the efficient one as values can not be mutated.

@pschanely
Copy link
Owner Author

pschanely commented Nov 11, 2022

Indeed; I recall some of that! In general, CrossHair should be able to construct via the signatures on __new__ and __init__ appropriately.

Even after construction, though, I expect some additional hurdles for classes extending some of the core types: str, list, dict, etc. Needs more investigation!

I believe many of the python-by-contract classes were never actually instantiated - that is, the __new__ just returned its argument. Those cases hopefully aren't subject to such challenges.

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

No branches or pull requests

2 participants