
On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Nov 30, 2021 at 02:30:18PM +0000, Paul Moore wrote:
And to be clear, it's often very non-obvious how to annotate something - in https://github.com/pfmoore/editables I basically gave up because I couldn't work out how to write a maintainable annotation for an argument that is "a Path, or something that can be passed to the Path constructor to create a Path" (it's essentially impossible without copy/pasting the argument annotation for the Path constructor).
You're after https://docs.python.org/3/library/os.html?highlight=pathlike#os.PathLike: `str | PathLike[str]` (if you're only accepting string paths).
I thought that type inference was supposed to solve that sort of problem? If the typechecker can see that an argument is passed to the Path constructor, it should be able to infer that it must be the same types as accepted by Path.
I would change that "should" to "may". Python's dynamism makes inferencing really hard.
Aside: I'm a little disappointed in the way the typing ecosystem has developed. What I understood was that we'd get type inference like ML or Haskell use, so we wouldn't need to annotate *everything*, only the bits needed to resolve ambiguity. But what we seem to have got is typing like C, Pascal and Java, except gradual. Am I being unreasonable to be disappointed? I'm not a heavy mypy user, I just dabble with it occasionally, so maybe I've missed something.
It really depends on the code base. Type checkers can make guesses based on the code they have available to them, but that only works if the usage is really clear and the dynamic nature of the code doesn't make things murky. For instance, look at open() and how whether you opened a file with `b` or not influences whether the object's methods return strings or bytes. What would you expect to be inferred in that case if you didn't annotate open() with overrides to specify how its arguments influence the returned object? It also depends on how lenient your type checker is willing to be. Compiled languages get to know all potential inputs and outputs of a function upfront, while Python it's a guess based on what you happen to have installed since you can always just `importlib.import_module()` anything at any time. But since type checkers typically prefer false-positives over false-negatives for correctness, it means having to clarify more code.
Anyway, we're *way* off topic now, and I doubt there's much that the SC or python-dev can do to change the community view on typing, anyway.
Heh. We could update PEP 8 to ban type annotations, then watch as the people who over-zealously apply PEP 8 to everything AND over-zealously insist on adding type annotations to everything have their heads explode.
-- Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Y6GOWIZV... Code of Conduct: http://python.org/psf/codeofconduct/