On Sun, Sep 10, 2017 at 10:06 AM, Rick Johnson <rantingrickjohn...@gmail.com> wrote: > Ian wrote: >> Rick Johnson wrote: >> > Ned Batchelder wrote: >> > > Leam Hall wrote: >> > > > >> > > > I've read comments about Python 3 moving from the Zen of >> > > > Python. I'm a "plain and simple" person myself. >> > > > Complexity to support what CompSci folks want, which was >> > > > used to describe some of the Python 3 changes, doesn't >> > > > help me get work done. >> > > >> > > I've heard a lot of FUD about the Python 3 transition, >> > > but this one is new to me. What is it that CompSci folks >> > > want that developers don't want, that ruined Python 3? >> > >> > TWO WORDS: "Type" and "Hints" >> >> Fail. >> >> 1. Type hints were only added in 3.5, not Python 3.0, so >> this does not support the claim that Python 3 changes were >> made to support CS. > > But it is true that CS purist want type annotations
Citation needed. > "Practicality beats purity". That's an odd mantra to use when you're arguing against a practical feature in favor of keeping the language "pure". >> 2. Type hints are completely optional, so this does not >> support the claim that Python 3 added complexity that is >> counter-productive to "simple" users. If you want to keep >> your program simple, you can: just don't use them. > > True, individual programmers can choose to omit type-hints > from their own code, but they cannot choose to omit type- > hints from the code they are forced to read. Once type > annotations start propagating in the wild, the syntactical > noise of statically typed languages will be ever-present in > Python code, only problem is, we will get *NONE* of the > advantages of _real_ statically typed languages, namely: > executables, compiler optimizations, and enhanced execution > speed. Heck, all we get in return for our painful eyeball > parsings are (maybe) better linters. Which is not an ROI > worthy of my sweat equity. Type hints aren't just for compilers, in the same way that comments are not for compilers, well-named variables are not for compilers, and readable code in general is not for the benefit of compilers. >> 3. Type hints are practical. You may not need or desire >> them for pet projects, but large-scale projects with a >> large team of developers require a large degree of testing. >> Static typing supports this. This is a feature for >> enterprise users, not theorists. > > I was never against Python having a type annotation feature, > no, i am only against the inclusion of this syntacticly noisy > feature in the .py[w] files. Mandating that type annotations > be defined in _external_ stub files places the onerous on > those who care about type annotations (a micro minority of > CS purist), and removes it from those who don't (the > remaining majority of Python programmers). If you're trying to actually understand the code that you're reading, then having the type hints swept off in another file to be "out of sight, out of mind" does not excuse you from the responsibility of knowing and understanding what the type expectations of the code are. You can guess, or you can read the author's explicit intentions. I know which one I prefer. Stub files exist for cases where it's not practical to type-hint the actual code, such as third-party libraries that you want type hints for but that you're not the maintainer of. Keeping type hints together with the actual code is always preferable. You don't have to care about type annotations, but when they happen to be present, then everybody should care, because they're useful. By the way, "onerous" is an adjective, not a noun. -- https://mail.python.org/mailman/listinfo/python-list