On Tue, 2021-04-13 at 09:43 +1000, Hugh Fisher wrote: > In any Python 3.6 or later, type > > >>> x : float = 1 > >>> isinstance(x, float) > > or replace the second line with > > >>> type(x) > > As someone who has programmed in FORTRAN, Pascal, C/C++, > Java, and Go this is not at all what I consider reasonable. I do not > believe other programmers with experience in typed languages > would expect this behaviour either.
Python is not a typed language, it is a language with optional typing. > Having a type checker run before the Python interpreter in our > current day continuous build/integration environment adds a > second step and therefore the chance for it to be forgotten, for > version mismatches, for warning/error reports to be misdirected. > From an environmental point of view we're also doing the read > source, lexical scan, syntax parse twice rather than once. This is simply not a good point in itself, and on top of that it seems to completely ignore that Python could be untyped, which is something I am almost certain won't likely change ever. At the very least you would have to pass a flag to the interpreter to run the type checker, which completely invalidates your "people will forget it if they have to explicitly run it" point. > If typing is the future of Python, and the number of PEPs being > worked on suggests that it is, then type checking should be > integrated into CPython itself. Why? There is a type checker living under the same umbrella organization. What is the reasoning for the type checker to be included with the interpreter, especially given that it is entirely optional? All I can think of are reasons *not to* include it with the interpreter, mainly that it would be bound to the same super slow release cycle. Please also consider that a type checker is something that no user will have to run, only developers. > An alternative is the TypeScript/JavaScript model, where typed > Python becomes a distinct programming language that cannot > be executed directly by the Python interpreter. Why?? This reads like "let's break stuff that is absolutely working" for no real discerning reason. Why would you do this? -- Why would we break workflows that work? Why would we add a code generating step to typed Python code? I am really struggling here to understand what would be the benefit here, it seems you want to make it slightly harder for people to forget to run it, by either making it always run or forcing a new code generation step. Overall, I find that you are trying to apply concepts from other languages and environments to Python, without really taking into account what they would mean for the Python ecosystem. While it is a great idea to look at other languages and try to align ourselves with some of their designs, as a way to make the user experience easier for some, it is also okay to not design things in the same way. We need to take into account the requirements and current state of our own environment, and try to understand what is the best option for us. Benefits and drawbacks will vary, so it is absolutely valid to come up with different answers. Please do not take these comments personally, in a verbal setting I would try to use social cues to try to pass the feedback more lightly. This sort of communication medium can make things easily pass as harsh, but that is not my goal. I just want to make sure we are on the same page, if you have answers for any of my questions, please let me know, but try to make sure you are taking into account you what real impact your proposals would have on the Python ecosystem. Cheers, Filipe Laíns
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/ENAUW2P3FDJOMJXQKLTLT4G7APLEQCJI/ Code of Conduct: http://python.org/psf/codeofconduct/
