Please let's not try to make Python a "typesafe" language. The success of Python owes a lot to the fact that duck typing is approachable, flexible and powerful.
Even if you advocate static typing, I think it's a very good idea to limit the ambition of the type system if you want to keep most users happy—despite the opinion of language lawyers. Go is by far the most successful statically typed language created so far in the 21st century, and I believe a lot of that success is due to the simplicity of its type system. It's way more successful than Rust, possibly for this very reason. I find it admirable that Go was released without generics, which were seriously considered only after its runaway success. Generics will appear in Go 1.17, scheduled for August, 2021—9 years after Go 1.0. Please let us heed the wise words of Brian W. Kernighan and Alan A. A. Donovan in the introduction of "The Go Programming Language" book, a masterpiece (even if you don't like the language, the book is one of the best introduction to any language that I've ever read): """ Go has enough of a type system to avoid most of the careless mistakes that plague programmers in dynamic languages, but it has a simpler type system than comparable typed languages. This approach can sometimes lead to isolated pockets of ‘‘untyped’’ programming within a broader framework of types, and Go programmers do not go to the lengths that C++ or Haskell programmers do to express safety properties as type-based proofs. But in practice Go gives programmers much of the safety and run-time performance benefits of a relatively strong type system without the burden of a complex one. """ I also consider the support of static duck typing and goose typing (via runtime type assertions and type switches) key factors that make Go an excellent language to "get stuff done"—the best compliment Dave Beazley traditionally has for Python. Cheers, Luciano On Thu, Apr 22, 2021 at 12:05 PM Paul Moore <p.f.mo...@gmail.com> wrote: > > On Thu, 22 Apr 2021 at 15:22, Adrian Freund <m...@freundtech.com> wrote: > > > > On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore <p.f.mo...@gmail.com> > > wrote: > > > >but that's *absolutely* as far as I'd want to go. Note in particular > > >that I don't want to constrain the return value > > The problem is that this isn't enough to have a type safe program. You need > > to also constrain the return type to make sure the returned value can be > > safely passed to other functions. > > But I don't want a type safe program. At least not in an absolute > sense. All I want is for mypy to catch the occasional error I make > where I pass the wrong parameter. For me, that's the "gradual" in > "gradual typing" - it's not a lifestyle, just a convenience. You seem > to be implying that it's "all or nothing". > > > If you don't do this large parts of your codebase will either need explicit > > annotations or will be unchecked. > > That's just not true. (And even if it were true, you're assuming that > I care - I've already said that my goal is much more relaxed than > complete type safety). > > I repeat, all I'm proposing is that > > def f(x: int): ... > def g(x: str): ... > > def main(t: DuckTyped) -> None: > if t[0] == 'version': > f(t[1]) > elif t[0] == 'name': > g(t[1]) > > gets interpreted *exactly* the same as if I'd written > > class TType(Protocol): > def __getitem__(self, int): ... > > def f(x: int): ... > def g(x: str): ... > > def main(t: TType) -> None: > if t[0] == 'version': > f(t[1]) > elif t[0] == 'name': > g(t[1]) > > How can you claim that the second example requires that " large parts > of your codebase will either need explicit annotations or will be > unchecked"? And if the second example doesn't require that, nor does > the first because it's equivalent. > > Honestly, this conversation is just reinforcing my suspicion that > people invested in type annotations have a blind spot when it comes to > dealing with people and use cases that don't need to go "all in" with > typing :-( > > Paul > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/CUZNKEA357N3672CCRA7DZ6C4WABN6FK/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/STAULSS6WI7DLSHEXYXHFLHQFVWAIAKY/ Code of Conduct: http://python.org/psf/codeofconduct/
