On Tue, 13 Apr 2021 at 12:09, Filipe Laíns <la...@archlinux.org> wrote:
>
[ munch ]
>
> Python is not a typed language, it is a language with optional typing.
Well, it's a dynamically typed language. And yes I agree, I want typing
to remain optional. I am happy that I can write
x = 1
x = [ "hello", "world" ]
x = ExtremelyComplicatedObject()
without even having to qualify it as
x : object
> > 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.
This is my second (and somewhat preferred) proposal where type hints
are recognised by the CPython interpreter, but they would remain optional.
So no flag needed. If there aren't any type hints, that's fine. If there are
type hints, assume they are there on purpose and parse and check.
> 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.
Getting slightly off topic, I have always thought that one of the strengths
of Python is that every use is a potential developer. If you have a Python
program and a text editor, you can change it. No special tools required.
> 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.
This is the model used by TypeScript (and various other dialects of JavaScript)
and it works for them. The big advantage is that the Python interpreter does
not need to know about typing, so no PEP 543 and no PEP 649, which is
currently generating a lot of esoteric (to me) discussion on python-dev.
> 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.
No complain from me Filipe, you're doing better at this than I am.
--
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/76EQHZLNMVWVSBIM5XBHHTKPXP7EJLLJ/
Code of Conduct: http://python.org/psf/codeofconduct/
