Skip to content
This repository has been archived by the owner on Mar 23, 2019. It is now read-only.

RTTC vs static analysis and centralizing coercion #4

Open
knappador opened this issue May 9, 2018 · 0 comments
Open

RTTC vs static analysis and centralizing coercion #4

knappador opened this issue May 9, 2018 · 0 comments

Comments

@knappador
Copy link
Owner

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:

  1. Draw a graph of all valid coercion paths and useful make_* methods that connect the type graph
  2. Graph should create an inverted DAG from the target type
  3. Convert DAG to a tree via arbitrarily favored paths
  4. Implement the rest of the _auto_arg helpers
  5. 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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant