Cool, thanks for your input. Personnally I am not a big fan of python's 3 typing (at least yet). I understand that being a duck typed language, having the type of return and to the argument type in the same function definition could be useful, but they don't replace the docstring do they? You still have to wright docstrings because most of the time you want to a little description. Also the IDE, by just hovering over the function, it tells you what you wrote in the docstring. I don't know, i am not sure how to feel about that in python 3. It seems adding redundancy in code.
So you don't docstring protected or private methods ( understanding that there is no 'protected' or 'private' in python, but that's another discussion). Protected methods are meant to be used in subclasses so I think you probably want to docstring them too. Maybe just skip private's docstring then? R El domingo, 2 de mayo de 2021 a las 21:27:18 UTC+2, justin...@gmail.com escribió: > My take is that I want to see docstrings on public functions (which as > you pointed out are different from comments). > One added benefit of writing a docstring is that doc generators like > sphinx, and IDEs, can produce helpful type linking and hinting. So if your > function takes a certain type and returns a certain type, you may be able > to get links to those types for more information. Also docstrings are > helpful for an IDE to perform type hinting in python2. I know that in > python3 we gain proper language-level type annotations, but for now we have > to do it through comments and docstrings in python2. > > It may be subjective for a developer to think > that calculate_inverse(matrix) "obviously" accepts a numpy ndarray as its > input type, and then chooses not to document it in a docstring. But what if > there are different types that could be considered a matrix object and it > is really not so obvious to someone reading the docs or the signatures and > only sees that your api expects a "matrix"? Better to just use the > appropriate docstring formats to add type information, until everything is > python3 and you can do it all via type annotations. > > > On Mon, May 3, 2021 at 6:30 AM Rudi Hammad <rudih...@gmail.com> wrote: > >> >> This not strictly related to maya but I wonder how you feel about it. >> In sumary, I found my self in similar situations as this: >> docstring example >> <https://stackoverflow.com/questions/33019955/should-you-always-document-functions-even-if-redundant-specifically-python> >> >> I think the link above isn't really answering what is was asked. >> He was asking about docstrings and people where responding to comments. I >> agree that unless necesarry your code shouldn't need any comments if you >> respect some programing princpiples. So you never find your self in long >> functions that requieres explanations with comments. >> >> But what about the docstring in that example? If you are methodic in your >> documentation and document everything, you will end up many times writing >> docstrings longer than the functions it self. I don't think it is something >> bad, just annoying. >> Also some programs generate automatically documentation for your api. For >> instance I use sphinx-doc and all exisiting docstrings are parsed and >> nicely documented automatically. >> >> what is your take on this? >> >> R >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to python_inside_m...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/01a95b10-0d22-424d-9d10-b8642efbfab9n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/01a95b10-0d22-424d-9d10-b8642efbfab9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/fb391bd2-1019-4be7-9eae-07aa42d12589n%40googlegroups.com.
