Let BT theorize what types would get through functions by comparing builtin structures with attribute interactions in the functions ast.

[CodyKochmann]

Let BT theorize what types would get through functions by comparing builtin structures with attribute interactions in the functions ast. The snippet below is a start to the mappings of attributes so they can be later crossed with ast tree analysis.

# attr_mappings.py
# by: CodyKochmann

# this is a set of the standard types available in python
standard_types = { bool, bytearray, bytes, complex, dict, float, int, list, set, str, tuple }

# this is a list of all default objects from the standard_types
standard_defaults = [i() for i in standard_types]

# this maps all the attrs of each type
type_to_attr_map = {type(i):tuple(sorted(k for k,v in inspect.getmembers(i))) for i in standard_defaults} 

# this is a set of all attrs from all standard_defaults
joined_default_attrs = set(sum((tuple(k for k,v in inspect.getmembers(i)) for i in standard_defaults), tuple()))

# this is a dict with {attr_name:{type1, type2, type3}} which maps out what types have what attrs
# this can be used by a inspector that looks at a function's ast tree to get 
# clues about what types of variables the function seems to be built to handle
attr_to_types_map = {a:{type(d) for d in standard_defaults if hasattr(d, a)} for a in joined_default_attrs}

[marcinpohl]

what about more subtle differences like list or array vs deque(N) or dict vs DefaultDict?

[CodyKochmann]

The lack of the collections library was on purpose. once the basic types are working well, a custom additional types interface will be added. This is because up until now, all type handling is very... Hand jam? Which is fine to a certain degree, but eventually needs to be automated so it can intelligently extend itself for the users the same way generators.Generator.add_method can.

Ideally collections will be a solid base test dataset to get that functionality working.