You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would seem like this would severely limit the value of APIView for Python. I tried to use it to verify that regenerating Swagger only added a single new property, but instead it showed no diff.
The text was updated successfully, but these errors were encountered:
If I change the docstrings from :param to :ivar then they appear in APIView. However, autorest generates models, some with :param and others with :ivar. @iscai-msft can you shed some light on how it makes that distinction?
defprop_documentation_string(prop: Property) ->str:
# building the param line of the property docifprop.constantorprop.readonly:
param_doc_string=f":ivar {prop.name}:"else:
param_doc_string=f":param {prop.name}:"
I don't know the rationale for why constants are ivar and everything else is param, but assuming it is sound, should APIView also expose params? Or should we somehow examine the init to determine what are actually properties, since it's entirely possible an init param could be consumed and not set on the object with self.foo.
@tjprescottparam basically means we accept this as an input parameter. ivar means it's a variable. Sometimes, the inputted param will also end up being a variable. Hope this clears it up!
I have a Python class that creates a bunch of public properties in its initializer, but APIView does not display any of them.
It would seem like this would severely limit the value of APIView for Python. I tried to use it to verify that regenerating Swagger only added a single new property, but instead it showed no diff.
The text was updated successfully, but these errors were encountered: