feat: runtime typechecking - #5375
mayankansys wants to merge 22 commits into
Conversation
Up to standards ✅🟢 Issues
|
| return x | ||
|
|
||
| assert fn(1) == 1 | ||
| with pytest.raises(BeartypeCallHintParamViolation): |
There was a problem hiding this comment.
Ideally, we should not directly emit beartype specific exceptions from PyFluent and ask our users to handle them. The backends-specific exception should be kept behind a PyFluent-owned exception.
There was a problem hiding this comment.
Correct @mkundu1. I have added it now, initially planner to make it Pyfluent owned exception in the Phase 2.
github-actions
Bot
added
documentation
| TConfig = TypeVar("TConfig", bound="Config") | ||
|
|
||
|
|
||
| # ``TConfig`` is bound to a forward reference which cannot be resolved while the |
There was a problem hiding this comment.
Should we keep the decorator ? If we didn't put the decorator we get the beartype.roar.BeartypecallHintForwardRefException.
…nsys/pyfluent into feat/Runtime_typechecking_4739
| @@ -0,0 +1,391 @@ | |||
| # Copyright (C) 2021 - 2026 Synopsys, Inc. and ANSYS, Inc. All rights reserved. | |||
There was a problem hiding this comment.
This is the demo script file for the local testing only. This will be removed later.
| >>> config.runtime_type_checking | ||
| True | ||
|
|
||
| Passing an argument of the wrong type then raises a ``beartype.roar.BeartypeCallHintParamViolation``. |
There was a problem hiding this comment.
This should be updated with the new pyfluent-specific exception type.
There was a problem hiding this comment.
Sure. I'll do in the upcoming commit.
mkundu1
left a comment
mkundu1
left a comment
There was a problem hiding this comment.
Changes looks good. Are we already running something in the CI (which would require installing the optional ansys-fluent-core[type-checking] package in the CI workflow)?
@mkundu1 No, the type-checking extra is NOT currently installed in CI. But planned to add in the last phase. Would it be correct to add in the last phase. Is it the correct approach or should I add it in the current phase. |
This branch has not been deployed
3 participants
Context
PyFluent had no runtime type-checking mechanism to catch API misuse early. Type errors propagated downstream as obscure failures, making debugging difficult for users. This PR opt-in runtime type-checking support (e.g., via beartype), configurable via environment variable.
Change Summary
This PR implements abstraction layer + config, implicit-Optional fixes and decorator fixes.
_type_checking.pywhich is a thin wrapper around the type-checking library. (e.g., via beartype)Impact
Now Pyfluent will support the runtime typechecking. When disabled (the default), there is no impact on the API surface. When enabled, type violations are reported as PyFluentTypeCheckingError exceptions. The feature is optional and can be installed via
pip install ansys-fluent-core[type-checking]users who do not install the type-checking extra can continue using PyFluent without beartype.#NOTE: There are further upcoming PRs as well.