fix: type checking #993
fix: type checking #993
Conversation
There was a problem hiding this comment.
This is a massive amount of new code that will only serve to present additional overhead when developing. The internal API is not public. A decision was made in #750 to use Python wrapper classes as the method for public-facing type checking.
internal api type annotation is not for user of this library，it's useful for developer of this library. automated tools can be used to gurarantee code quality. i annotated the intetnal api，then i can easily find several bugs via pyright. |
|
There's no guarantee that those internal types will match the actual runtime types from Rust. So in effect this adds another layer of types that must be manually kept up to date on every PR. In that way, I don't see where the benefit comes in. We already have developer type checking on the Rust side. |
ok. if you dont think its necessary， i will remove the annotation and only commit the bug fix. |
Let's let another developer chime in as well. This is just my opinion. What are the bug fix(es)? |
| @@ -66,9 +66,10 @@ def __init__(self, table: df_internal.Table) -> None: | |||
| """This constructor is not typically called by the end user.""" | |||
| self.table = table | |||
|
|
|||
| @property | |||
There was a problem hiding this comment.
This is changing the user-facing API, no?
There was a problem hiding this comment.
i checked the test，i think we should use @ property， but previously we didnt do wrapping somewhere， raw table is returned that's why test passed.
|
most bugs are wrapping or unwrapping missing，since we have wrap classes. |
Which issue does this PR close?
No
Rationale for this change
pyo3 native code has no python type, without type hint, it's error prone.
What changes are included in this PR?
Are there any user-facing changes?
No