On Fri, Sep 25, 2020 at 3:03 PM Paul Moore <p.f.mo...@gmail.com> 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. > > 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? > Exception docstrings contain the Exception type and the explanation str: (type, docstr) Exception annotations as proposed contain the Exception type: (type) and presumably then docstrings would also be expected to contain (type, docstr); which isn't DRY. But annotations are parseable and more commonly linted. > > My problem with the proposal is that it's about adding a mechanism, > without any clear statement of how that mechanism is intended to be > used. And there's so much scope for misguided use, and so few clear > benefits, that it feels like a bad trade-off at the moment. (For the > record, I'm not convinced by the IDE argument. I use Vim, which is > relentlessly primitive in its basic form, and wouldn't use anything > like this, and VS Code, which is so clever that it seems like magic > most of the time, and I'm pretty certain that if people wanted it, VS > Code could include "exception autocompletion" even without explicit > annotation like this). > LSP servers and clients: https://langserver.org/ - https://github.com/microsoft/python-language-server - https://code.visualstudio.com/api/language-extensions/programmatic-language-features - AFAIU, there's not yet anything in any LSP Language Extensions for statically or dynamically discovering exceptions from the DFS of all references to types and callables of a callable (Type) Annotation type inference tools: pytype (Google) [1], PyAnnotate (Dropbox) [2], and MonkeyType (Instagram) > [3] all do dynamic / runtime PEP-484 type annotation type inference [4] > [1] https://github.com/google/pytype > [2] https://github.com/dropbox/pyannotate > [3] https://github.com/Instagram/MonkeyType > [4] https://news.ycombinator.com/item?id=19454411
_______________________________________________ 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/DBYCXFI3ZQDNHZJGQ6BV7QKX7STHWUDQ/ Code of Conduct: http://python.org/psf/codeofconduct/
