Hugh Fisher writes: > In any Python 3.6 or later, type > > >>> x : float = 1 > >>> isinstance(x, float) > >>> type(x) [snip] > As someone who has programmed in FORTRAN, Pascal, C/C++, > Java, and Go this is not at all what I consider reasonable.
>From the point of view of typing, you've programmed in one other language. ;-) (Maybe Go makes two, I haven't used it.) They all demand that variables be declared with types, and then proceed to fill them with bit patterns that can't be introspected (unless you build it in to class definitions yourself). 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. If, on the other hand, you want explicitly typed variables (and not just "if we must have types, I want them integrated", I think you'll have a serious fight on your hands. It's often quite useful to me, for one, that names are not typed while objects are. > 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. This is a good point, but having an explicitly typed language would mean I can't really use Python at work (that is, I can't recommend it to my business and economics students, who don't program, really, they record scripts). > 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. > 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. I don't see it as *the* future of Python. And I don't really see why it should be integrated into CPython. To me it seems to be a language facility, not an implementation facility. Integrating it with CPython would likely result in disintegrating it from PyPy and other implementations. I don't think that is desirable at all -- the version skew you mentioned would likely occur here. I like to think of it as "Python typing has some warts, but that's because it will turn out to be a prince(ss) when you kiss it." 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/IFS5X4WQDKQANCQH6DULA2HPA6B6K7GH/ Code of Conduct: http://python.org/psf/codeofconduct/
