
On Tue, 30 Nov 2021 at 19:07, Brett Cannon <brett@python.org> wrote:
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).
Well, it's not really. What I'm after, as I stated, is "anything that can be passed to the Path constructor". Yes, str | PathLike[str] is probably close enough (although why is it OK for me to prohibit bytes paths?) but that's what I mean about copying the Path constructor's annotations. If Path changes, I have to change my code. This is a very common idiom: def f(p: ???): p = Path(p) ... Why isn't it correspondingly straightforward to annotate? If PathLike[str] included str, then it would be a lot easier. It's not at all obvious to me why it doesn't (well, that's not entirely true - it's because PathLike is an ABC, not a protocol, and it's not intended to define "the type of objects that the Path constructor takes"). It would still not be documented anywhere, though.
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.
That's fair. That's why I think it should be straightforward for the user to explicitly say "this argument should accept the same types as pathlib.Path does". If inference can't do it automatically, and the user can't (easily) let the checker know that it's OK to do it, then we're left with no easy way to express a very common pattern.
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?
Personally, I'd be quite happy leaving open() as duck typed. I see this as what Steven was getting at - the "typing ecosystem" has moved into a situation where it's acknowledged that some typing problems are really hard, due to Python's dynamism, and yet there's still a drive to try to express such highly dynamic type constraints statically. And worse still, to insist that doing so is somehow necessary. Whatever happened to "practicality beats purity", and typing being "gradual"? Surely annotating everything except open() is practical and gradual? Paul