On Tue, 13 Apr 2021 at 20:30, Stephen J. Turnbull
<turnbull.stephen...@u.tsukuba.ac.jp> wrote:
[ munch ]
> > 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).
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.
> 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.
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.
[ munch ]
> 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).
I don't want Python to be explicitly typed either. I'm happy with dynamic
typing, and do not want to have to write even
x : object
> > 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.
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.
[ munch ]
> 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."
Yes, perfect is the enemy of good enough. I'm reading (OK, skimming)
the emails about implementing PEP 649 on this list and I'm seeing
significant problems in the current tools, not just cosmetic.
--
cheers,
Hugh Fisher
_______________________________________________
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/ANIPH3CFWDWIP2SRN2YQVPWR5I3KNIPD/
Code of Conduct: http://python.org/psf/codeofconduct/
