Properties are rendered with parens

[bear24rw]

Describe the bug
@property's are rendered with trailing () which makes them look like functions.

To Reproduce

class Example:
    @property
    def foobar(self):
        """
        Return the value of the foobar property
        """
        return 42

Expected behavior
I expect the heading in the API docs to be just foobar but it is rendered as foobar()

System (please complete the following information):

mkdocs==1.2.3
mkdocs-autorefs==0.4.1
mkdocs-material==7.3.4
mkdocs-material-extensions==1.0.3
mkdocstrings==0.18.1
mkdocstrings-python==0.6.6

[pedrolabonia]

Since the new griffe version creates labels, should we do it on the templating side? We can do a simple check to see if the Function object passed by griffe has 'property' in object.labels.

I don't know if this can be solved directly on the Jinja template or if we need additional context from Griffe.

If we could have some direction I can try to help.

Im trying to figure out exactly where the connection between griffe and mkdocs-python is.

Edit: I've figured it out, seems easy enough to do it on the template itself. I'm working on it.

[pawamoy]

You guessed right! I was exactly planning to add a check in the templates 🙂 I'm glad to hear you're working on it, should I wait for a PR then 😄 ?

[pedrolabonia]

You guessed right! I was exactly planning to add a check in the templates 🙂 I'm glad to hear you're working on it, should I wait for a PR then 😄 ?

Yes!

Also, one question... Right now, @property getters and setters are marked as functions, and you've wrote tests do assert so.

Do you want to keep that design, or should we pass them as attributes from griffe? From what I've saw that's how the old handler dealed with it. Got them as attributes straight from pytkdoc.

Just thinking about "economy" of code here, since griffe is telling all themes it's a function, and we'd need to adjust every theme.

It isn't an issue too, just a matter of which design decision you want to go with.

[pawamoy]

Griffe will always return a property as a function. That's just how it is technically. But when rendering API documentation, it makes sense to categorize them as attributes, since that's how they are used.

EDIT: well I'm wondering if Griffe itself shouldn't categorize properties as attributes directly. Griffe is supposed to build and manipulate API structures so that would make sense as well. I'll have to think about it more.

[pedrolabonia]

I agree that passing them as attributes from Griffe might be the best way. I can't imagine right now a use case where a property would be bundled with the class methods, but there might be some edge cases.

Doing it in Griffe avoids all the templating patching and logic for that specific case, and feels to me as more of an expected behavior.

If you have any ideas on how to go about this, I can try to help. I'll close the PR for now.

[pawamoy]

Doing it in Griffe avoids all the templating patching and logic for that specific case, and feels to me as more of an expected behavior.

Exactly!

If you have any ideas on how to go about this, I can try to help.

Let me bring the change in Griffe, then I'll give you some guidance to update the Python handler 🙂

[corykinney]

Just wondering if there has been any progress on rendering properties as attributes; I'm generating some documentation with quite a few properties and don't want anyone to be confused by them looking like functions.

EDIT: Also, I'm not sure if it's already possible, but it would be great if the attributes would also display the property return type hint.

[pawamoy]

This is now implemented and will be published with the next release of Griffe.