Hugh Fisher writes: > There are a lot of programmers like me. Those languages I listed > are widely used, and therefore we assume that if a Python language > construct looks like something we've used before, it will work in > the same way.
That's not very persuasive. When in London, England, you speak English, but you probably shouldn't assume that the words others use mean the same thing that they do in London, Ohio. Anyway, in which of those languages is "def foo(x:float = 1) -> int" legal syntax? What do you mean it "looks like" something you've used before? It looks to me like what you mean is "To me, declared types (no matter what they look like) aren't hints, types should be enforced." I agree, that's what you learn if your experience is restricted to common explicitly typed languages, but reality is more flexible than that. That's why I read manuals before using a new language or a feature newly added to a familiar language. :-) > > Python's different approach is a compromise. And as usual Guido's > > time machine (or somebody borrowed it) is in evidence: if that example > > bothers you, request that people around you who type things like that > > use stub files instead so you don't have to deal with it. > > And that would be the TypeScript style approach, "typed Python" is a > language that gets translated into non-type hinted dynamic Python. I can't agree. To me it's the same Python with typed objects and untyped identifiers it's always been, and that's a feature. The question is whether you see the hints in the implementation source, or in an auxiliary file. "Typed Python" as currently implemented is not a different language. It's the same language with extensive use of a previously little-used feature (function annotations). > No-one who works in JavaScript needs to deal with TypeScript > language features unless they want to. This is not true of the > current typing in Python. You *need* to deal with typing only to the extent of ignoring it. OK, one of the real selling points of Python is that its syntax is fairly economical, and type hints do have a cost in that sense. But the answer to that is "just don't", and go ahead and ask colleagues you share code with to "just don't" too. > > > From an environmental point of view we're also doing the read > > > source, lexical scan, syntax parse twice rather than once. > > > > This is not true. Most programs, *especially* programs that are > > complex enough to want type-checking, are run far more often than they > > are type-checked. > > Among the software devs I work with, testing and checking is something > you do *every* time you make a change. If I'm adding type checks to my > program, that's because I want them to be checked. And that's the last time anybody ever runs that program? That's certainly not true of any of the programs I would consider using type hinting for! Even the test suite will typically run mypy once, and the program itself many times since that's the easiest way to guarantee de novo initialization of the program's state for each test. > Historical example would be lint for C programs. Running lint > wasn't required before compiling your C code, but it was so useful > that a number of projects made it compulsory, and the functionality > of lint was eventually incorporated into the C compiler itself. I think the analogy is valid, but it doesn't support your position. See Brett's reply for why, I'm just +1-ing here. Steve _______________________________________________ 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/NCCQJXFHYPBKTUNXKHIWCE35N7UTWNVV/ Code of Conduct: http://python.org/psf/codeofconduct/
