Skip to content

Conversation

@tcoratger
Copy link
Collaborator

@tcoratger tcoratger commented Dec 15, 2025

πŸ—’οΈ Description

πŸ”— Related Issues or PRs

Should close #60

βœ… Checklist

  • Ran tox checks to avoid unnecessary CI fails:
    uvx tox
  • Considered adding appropriate tests for the changes.
  • Considered updating the online docs in the ./docs/ directory.

@tcoratger tcoratger marked this pull request as ready for review December 15, 2025 12:09
@tcoratger tcoratger requested a review from fselmo December 15, 2025 12:09
Copy link
Contributor

@fselmo fselmo left a comment

Choose a reason for hiding this comment

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

@tcoratger I added a cleanup commit and a nit commit directly after that replaces cast(Any, ...) logic with more explicit ignores and / or class definitions. These were only in the tests so I don't mind either way tbh. If you feel casting to Any is better or easier to read, feel free to drop that commit.

I noticed that the mypy pydantic plugin does a lot to help the code understand the type coercion that pydantic does. ty doesn't seem to have this and I'm not sure they ever plan on having it tbh. Things like Boolean(True), Boolean(False), etc instead of being able to use True, False and have pydantic convert to Boolean internally.

I'm not sure that this is necessarily a bad thing, it just makes things more verbose. For specifications, this seems totally reasonable so either way I am good with it - just making an observation here πŸ˜ƒ.

It's amazing how fast ty is πŸš€... this lgtm πŸ‘πŸΌ

@tcoratger
Copy link
Collaborator Author

@tcoratger I added a cleanup commit and a nit commit directly after that replaces cast(Any, ...) logic with more explicit ignores and / or class definitions. These were only in the tests so I don't mind either way tbh. If you feel casting to Any is better or easier to read, feel free to drop that commit.

I noticed that the mypy pydantic plugin does a lot to help the code understand the type coercion that pydantic does. ty doesn't seem to have this and I'm not sure they ever plan on having it tbh. Things like Boolean(True), Boolean(False), etc instead of being able to use True, False and have pydantic convert to Boolean internally.

I'm not sure that this is necessarily a bad thing, it just makes things more verbose. For specifications, this seems totally reasonable so either way I am good with it - just making an observation here πŸ˜ƒ.

It's amazing how fast ty is πŸš€... this lgtm πŸ‘πŸΌ

Thanks a lot for the review. For me, the fact that ty forces us to be more verbose isn't a problem; it actually brings us closer to more typed languages ​​and allows developers to realize what they're really doing, so that's pretty good.

Thanks for the commits, it looks very good now, I'll merge it now, that is much much faster than mypy :)

@tcoratger tcoratger merged commit 39bada9 into leanEthereum:main Dec 16, 2025
10 checks passed
fselmo added a commit to unnawut/leanSpec that referenced this pull request Dec 16, 2025
* python: replace mypy by ty

* fmt

* fix strange ignore

* bitfield fix

* element property method simplification

* rm useless ty rule

* bump ty

* fix conflicts

* small simplifications

* remove useless thing

* minor cleanup related to adding ty

* refactor: avoid cast(Any, ...), be more explicit with test models + ignores

---------

Co-authored-by: fselmo <[email protected]>
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.

Look into replacing mypy with ty once released

2 participants