Type hints aren't recursive

[alexiswl]

Given a function such as the one below

def get_project_data_obj_by_id(
    project_id: str,
    data_id: str
) -> ProjectData:
    """
    Given a project_id and a data_id, return the data object

    :param project_id:
    :param data_id:

    :return:
    """

    # Get the configuration
    configuration = get_icav2_configuration()

    # Enter a context with an instance of the API client
    with ApiClient(configuration) as api_client:
        # Create an instance of the API class
        api_instance = ProjectDataApi(api_client)

    # example passing only required values which don't have defaults set
    try:
        # Retrieve the list of project data.
        data_obj: ProjectData = api_instance.get_project_data(
            project_id=project_id,
            data_id=data_id
        )
    except ApiException as e:
        logger.error("Exception when calling ProjectDataApi->get_project_data_list: %s\n" % e)
        raise ApiException

    return data_obj

I can call this function to retrieve a project data object.

my_project_data_obj = get_project_data_obj_by_id("my_project_id", "my_data_id")

PyCharm IDE then gives me the following attributes as expected if I was to write my_project_data_obj.

However, despite the attribute data being of type Data - see https://umccr-illumina.github.io/libica/openapi/v2/docs/ProjectData/ or screenshot below

When I try and perform an action on the attribute, I don't get any helpful suggests, even though libica should know it's of type Data.

[victorskl]

This might be relating to late binding... I will see to it

[alexiswl]

Also running into issues where PyCharm won't highlight errors when I access attributes that don't exist

i.e

If I try and use project_pipeline_obj.status I have no error, but on runtime this will result in an error since I should have used project_pipeline_obj.pipeline.status instead

[victorskl]

I check this as well. Yup, I can reproduce.

As discussed, this entails upgrade to Python generator which will break backward compatibility, probably.

I have created milestone 3.0 as forward planning upgrade.