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
If you look at what that type actually is (i.e. whatever the type of defaultdict(dict) is), it might not be very helpful. I'll even argue that the comment is much more informative ;-)
Calling the modulefinder code "somewhat esoteric" is a bit of an understatement :-) MyModuleFinder is a thin layer on top of the Python std library modulefinder module, that fixes a couple of bugs that only show up in our use cases. The _depgraph field is where modulefinder leaves its result for us to pick up (it's a nested dict of nested dicts of ...).
I like types, but Python's type system is horrendously anemic and excessively verbose, e.g. the typing of sum ought to be able to be expressed very similar to:
def sum(vals: iterator[T], start: T) -> T: # an iterator producing something of type T, a start value of the same type, returning a value of that type
x = start # should never need to be typed, type inference should handle it
for v in vals: # ditto
x += v
return x
how many lines of type code do you need to write to get this to work in Python..?
I'll get off my soap-box now :-D
ps: PRs that add sensible typings (api interface boundaries) will likely be merged...
The current lack of type hinting is hindering using the API since there's a few somewhat esoteric parts.
Ideally comments like the DepGraph init comment:
# depgraph is py2depgraph.MyModulefinder._depgraph
would just have the actual type hinted.
The text was updated successfully, but these errors were encountered: