On Fri, 25 Sep 2020 at 13:46, Samuel Colvin <samcol...@gmail.com> wrote: > > Sorry I probably wasn't clear enough in what I was suggesting. > >> >> The main question here is why using a hint or a decorator should be >> better than a simple documentation. > > > For the same reason type hints are better than documentation - > > 1. static analysis can catch a multitude of potential errors that humans > often miss. > 2. type hints stay with code in a way documentation often doesn't > 3. developers are often forced to keep type hints up to date to get tests to > pass > the same is very rarely true of documentation, this would apply to > "exceptions raised" too.
Type hints were largely driven by developers of type checking software. Is there interest from the mypy developers in this sort of exception annotation? From any other static checking tool? If there's no-one proposing to actually use the proposed feature in a tool, it's not clear how the cost of implementing it is justified. You;ve discounted runtime checking (and everyone hates that anyway), and no type checkers have spoken up saying they want it. You mention IDEs, but if you look at the history of suggestions intended to support IDEs in this list, you'll find that they very rarely go anywhere. A significant proportion of Python users don't use an IDE. And generally, IDE developers don't seem interested in pushing new language features that they can use - I don't recall ever seeing an IDE developer speak up to say how much a proposed feature will help them. In practice, I think IDEs tend to work with heuristics or what they can do with the language as it is, and aren't really interested in shaping the language to be "IDE-friendly". But that's just my impression. There's also the problem that you've explicitly acknowledged, that exception hints are *always* going to be inaccurate, in stark contrast to type hints which are expected to be correct when used. Enumerating all possible exceptions is impossible, and (as Java's checked exceptions shows) typically does more harm than good. No exception hints is where we are now. You're suggesting a feature that lets people list "some" exceptions - somewhere in the spectrum between "all" and "none" - but it's completely unspecified what exceptions need to be included and what don't. "Whatever the developer feels is appropriate" is basically useless - there's no way any tool or user can usefully interpret what an exception hint means if things are this wide open. I can't see how anything could make any practical use of the data the proposal offers... Paul _______________________________________________ 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/ERXDU7SOOILCVS4N7CD2TBSZ2WR6HKXW/ Code of Conduct: http://python.org/psf/codeofconduct/
