No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

<@U01038HJ93R> I noticed on github you worked on this a lot, would you be able to comment please? To confirm this is a problem so we open the issue.
Thank you

Hey! So, the TL;DR is you’re right about some of this, and some of it is a little obscured. I captured the issues in detail over at <https://github.com/pulumi/pulumi/issues/7367>, you might be able to get some information there to get it to work for you but we do have some work to do.

&gt; I wonder if pulumi adheres to any of the styling guides or “just generates docstrings”
:laughing: nice

FWIW, we use reStructured Text - but VSCode and PyCharm actually prioritize different formats. PyCharm likes reStructured, VSCode prefers Google-style docstrings :shrug::skin-tone-4:

Yeah and I prefer Numpy style :smile:

However, Goolge style classes suggest naming attributes in class docstring which can actually fix the   problem at least partially :slightly_smiling_face:

<https://google.github.io/styleguide/pyguide.html#384-classes>

<@U01038HJ93R> I also found this issue:
<https://github.com/pulumi/pulumi/issues/5142>

Then I did some research and found SO post from the author of `enum` python package and he created another package called `aenum` - that could solve the probelm in 5142

<https://stackoverflow.com/questions/52062831/how-do-i-properly-document-python-enum-elements>

image.png

nvm Pycharm can handle docstring under the value
while VSCode don't

Downside of Auto enum is that the result shows as potential tuple in quick documentation but is not subscriptable

Speaking of doc what is making
picture 1 is from `a`, picture 2 is from `b`

<@U025964HAJH> appreciate you looking into this. Please leave these comments in the issue so we can have a record when we go to fix, we’d like to keep github issues as the place to discuss bugs and possible fixes as we don’t all monitor this slack and it may not be me working on the issue :slightly_smiling_face:

yes I just wanted to make sure we want to track this in a single issue not a separate one