On Sat, 13 Feb 2021 at 17:33, Guido van Rossum email@example.com wrote:
On Sat, Feb 13, 2021 at 2:38 AM Paul Moore firstname.lastname@example.org wrote:
I have to agree here. I'm not a frequent user of type hints yet, but I am starting to have to maintain code that has type hints, and from a maintenance perspective, I have to say that this would be really hard to deal with. If I saw this for the first time "in the wild", I'd have no idea what to do with it.
Think of it as new syntax. Of course you have to learn it (or Google it). Is it easy to learn? I think so. Is it easy to recognize once you've seen and understood it once? Yes. Is it easy to use it correctly given an example? Yes again.
But looking at it, it's *not* new syntax, it's a return type of TypeGuard[List[str]], which is perfectly good syntax today. I can look up what the type TypeGuard is, but most of the time, when maintaining code, I don't do that - I just think "hmm, returns Foo, that's all I need to know right now". But then I discover that it's returning a boolean, and I'm confused. And it's always going to be an exception to the rule that what's after the -> is the type of the return value. I personally think "Special cases aren't special enough to break the rules" applies here, but I admit I don't know how special this case is, nor do I know why no less exceptional alternative is possible.
Of course I can look it up, but it's a distraction from what I was trying to do. Of course it's easy to google, but it's the *only* annotation I've ever needed to google. Of course it's optional and only affects type checkers, but I don't control everything that gets added to code bases I support.
*shrug* it makes little difference in the grand scheme of things, it'll go in if enough people who have influence over the decision are OK with it. And I'm sure it fills a need for certain types of project. It's not going to make my life impossible either way. But if impressions from casual users are being counted, I remain -1.