PyCharm autocompletion for properties

Due to the fact that the classes have dynamically generated fields for the AWS resource properties, IDEs like PyCharm doesn’t suggest those fields during autocompletion.

For example:

from troposphere import Template, apigateway

t = Template()

apiResource = apigateway.Resource("contactcloud")
apiResource.ParentId #<-- won't be suggested by autocompletion!

This could be remedied in two ways:

1. Add type hints to the beginning of classes, e.g.:

class Resource(AWSObject):
    ParentId: basestring    # Python 3 type hints for fields
    PathPart: basestring
    RestApiId: basestring
    
    resource_type = "AWS::ApiGateway::Resource"
    
    props = {
        "ParentId": (basestring, True),
        "PathPart": (basestring, True),
        "RestApiId": (basestring, True)
    }

2. Generate stub files

This is outlined by PEP 484#stub-files

[markpeek]

I’ve been busy but keeping an eye on this thread. Here’s some comments:

• First off, I will be making a series of changes to the layout of troposphere to keep backward compatibility but move the validators into a separate directory. This is needed to allow better code generation from the resource specification file.
• With the generator changes for the above, I will get the stub files generated (thanks @DrLuke) alongside the code files.
• In looking at the stub files it appears to allow for matching the parameters but not the types. This appears due to the use of kwargs in troposphere and there isn’t a great solution for typing on each kwarg.
• In this I want to move incrementally and preserve as much backward compatibly as possible, given the amount of existing code in production, while improving the ease of use.
• I will have to look harder at pydantic but initially I’m not a fan of the “title” change. Also, it seems PyCharms has a pydantic module but I don’t believe VS Code has one so there is still a gap.

Anyway, wanted to provide a quick update from my viewpoint. The key for me is to rely more on the generator to keep the library up to date with the resource spec, ensure reproducible results (due to renames that are required), and to generate the corresponding stubs accurately.

[ITProKyle]

@MacHu-GWU - Just want to echo the feedback that everyone else has provided. Changing the names of the properties kills its usability for me and my teams. I get that you are trying to differentiate required vs optional parameters but the appropriate way to do that would be by making the type annotation of the property Optional[type] not by changing the documented names of the properties. This is something that all modern IDEs display and provide feedback for before runtime (type checkers like pyright can also be used). I my opinion and that of other I work with, changing the names of the properties adds more complexity especially for the “low experience engineers” you are targeting.

That’s not to say cottonformation isn’t a nice library. It’s just not a replacement for Troposphere for a company with hundreds of Troposphere templates (which would take a significant amount of time to update EVERY property) and is not a solution to this problem.