On Fri, Sep 25, 2020 at 08:01:39PM +0100, Paul Moore wrote: > On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano <st...@pearwood.info> wrote: > > There may be practical difficulties in sticking exceptions into > > annotations. Annotations already can be pretty long and bulky. But if > > you are okay with functions documenting that they might raise a certain > > exception, then *in principle* you should be okay with moving that into > > an annotation rather than the docstring. > > > > Annotations are just a form of documentation in a consistent standard > > format to make it easy for IDEs to read them. > > Expressed that way, it's a reasonable argument. And to the extent that > we're talking about a way for functions to note what exceptions the > developer feels are worth mentioning, having a language construct to > do this would be OK.
Indeed. But the practical difficulties aren't trivial. There's the issue of mere ackwardness: there's already a tonne of information in a complex function signature, adding annotations pretty much doubles that, and adding exceptions could easily increase that again by fifty percent. More importantly, attempts in other languages to declare exceptions have been unsuccessful, if not counter-productive, for reasons that Chris explains. On the other hand, for many years before mypy came on the scene, IDEs parsed docstrings for parameter information, with at least four different standards for declaring parameters: - Epydoc - ReST format - Google's format - Numpydoc format https://stackoverflow.com/questions/3898572/what-is-the-standard-python-docstring-format There may be others, and all of these seem to have support for declaring the raised exception types, so presumably IDEs have been able to make use of this information for a decade or more and the world hasn't ended. > But in reality, people would treat the annotation as more definitive > than it is. And people would feel pressure to "stick to the contract" > when writing the annotated code. And style guides (which like it or > not are sometimes written by people who are *not* experienced > developers) will appear which state rules rather than allowing for > nuanced interpretation. All of which might not be how the feature was > intended to be used. I know, why assume the worst? But in contrast, > what's the *best* outcome? Yes, Chris does a good job of explaning the problems, and I'm not going to repeat them here. And the benefit seems small: so your IDE will autocomplete the exceptions for you. I think this may come down to this: - people who use IDEs think that autocompletion in general is a great feature and may want want to extend that to exceptions; - people who don't use IDEs think autocomplete is a very weak reason for adding a feature to the language. My own personal feeling is "so I don't have to look up the docs" is a weak feature, especially given that an abbreviated version of the docs are available from the interactive interpreter: help(some_function) The bottom line is that I think any impetus for this feature would have to come from the mypy and other static tools community. Can they use it? I don't think it's far wrong to say that if Guido and the mypy devs want this, they will probably get it, and if they don't, you probably won't convince them to add it just for the sake of autocomplete. -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7N5VR66P5AH4LHEMETVNHC5LI4D7CDZN/ Code of Conduct: http://python.org/psf/codeofconduct/
