I've spent a considerable amount of time manually deducing a return type from various libraries (usually I have Mypy set to not allow missing annotations).
I agree with Gregory here. Inferring function return types and inserting
the corresponding type hints where they are absent can be a feature of a
particular type checker, no need to add a special name for that.
One of the roles of type hinting in general is documentational. By
specifying the return type of a function explicitly you spare a future
reader from having to analyze the implementation and figuring it out
themselves. Specifying that a function returns Any, perhaps questionable
from API design point of view, is otherwise still useful. Such annotation
indicates that a caller should be ready for, well, any value. Specifying
Auto, on the other hand, doesn't tell anything. It's just a plug to please
the type checker, forcing a human being reading the code to deduce the type
manually all other again.
On Wed, May 27, 2020 at 8:11 PM Gregory P. Smith
On Wed, May 27, 2020 at 7:22 AM Mikhail Golubev via Typing-sig < typing-sig@python.org> wrote:
I believe that relying on a type checker-specific type inferencing behavior, intentionally left undefined by PEP 484, is what one normally indicate buy not specifying any concrete type, so just leaving "f2" not annotated in this case. If a type checker is able to deduce which type "f2" returns, it will. Having to use some special type for that will only unnecessarily clutter the code of all the small internal functions that otherwise don't need to be explicitly type hinted.
+1 agreed, there is no need for Auto. For example: pytype infers without that, it was designed to always infer.
The presence of an annotation is *generally* considered a sign that the user wants something different than inference currently comes up with, so it tends to be blindly trusted.
Obviously when you've got inference ability you could run that in a mode that highlights inference vs annotation incompatibilities or suggests alternatives to Any (as Any is by definition compatible with everything) - but that would be a type checker specific feature with no guaranteed correct behavior. (inferred things tend to be a lot messier looking and logically pedantic than a manual *intended* annotation)
Any is the weird case. It may be slapped on code to appease a code base or tooling that isn't yet ready to understand the ideal type. I generally advise against ever using it as a naked lone return type as it tends to destroy type information flowing through a code base when applied that way. There's a good chance an Any return type should be accompanied by bugs being filed as to why that was necessary at the moment.
-gps
-- Mikhail Golubev Software Developer JetBrains http://www.jetbrains.com The drive to develop