You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 23, 2019. It is now read-only.
Bottom line is the implementation and tools need to actually find bugs.
Connecting the type graph will tangle with enabling useful type checking. Plan for that:
Draw a graph of all valid coercion paths and useful make_* methods that connect the type graph
Graph should create an inverted DAG from the target type
Convert DAG to a tree via arbitrarily favored paths
Implement the rest of the _auto_arg helpers
Every outer signature coerces to the target types along the tree
Assuming we have a tree of methods in our constructors, it should become decidable whether a caller is providing enough information to construct a desired type. This does not address if the type checkers will give up for any number of reasons. Optional -> concrete may need to be completely explicit to satisfy sufficient information to construct.
The *Math metaclasses provide additional challenges for integration with type checking. The other arg could be type Any but this really only makes sense when we want to return NotImplemented for the sake of allowing the other to invoke it's __radd__ and related __r* methods. Commutative argument upgrading / downgrading is done via __r* methods now and is not particularly mind-blowing but it's not immediately clear that pylint can reason about simple math expressions ahead of runtime.
assert is being moved away from. The adoption of a favored tree of construction can deal with Optional and this process is reductive as we approach our canonical signature at the point of actual construction. The assertions on _auto* methods for non-None cases will then implement sensible RTTC where the user provided an argument and the argument breaks the reduction path. In this manner we can move away from almost all non-shared constructor coercion as well as providing tools for client classes to adopt the same type-checking.
Testing
Oddly some broken code will need to exist in the source base to verify the performance of pylint. Some integration will be necessary.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bottom line is the implementation and tools need to actually find bugs.
Connecting the type graph will tangle with enabling useful type checking. Plan for that:
make_*
methods that connect the type graph_auto_arg
helpersAssuming we have a tree of methods in our constructors, it should become decidable whether a caller is providing enough information to construct a desired type. This does not address if the type checkers will give up for any number of reasons. Optional -> concrete may need to be completely explicit to satisfy sufficient information to construct.
The
*Math
metaclasses provide additional challenges for integration with type checking. Theother
arg could be typeAny
but this really only makes sense when we want to returnNotImplemented
for the sake of allowing theother
to invoke it's__radd__
and related__r*
methods. Commutative argument upgrading / downgrading is done via__r*
methods now and is not particularly mind-blowing but it's not immediately clear that pylint can reason about simple math expressions ahead of runtime.assert
is being moved away from. The adoption of a favored tree of construction can deal withOptional
and this process is reductive as we approach our canonical signature at the point of actual construction. The assertions on_auto*
methods for non-None cases will then implement sensible RTTC where the user provided an argument and the argument breaks the reduction path. In this manner we can move away from almost all non-shared constructor coercion as well as providing tools for client classes to adopt the same type-checking.Testing
Oddly some broken code will need to exist in the source base to verify the performance of pylint. Some integration will be necessary.
The text was updated successfully, but these errors were encountered: