On 21/05/2017 06:41, Chris Angelico wrote:
On Sun, May 21, 2017 at 3:30 PM, Gregory Ewing
<greg.ew...@canterbury.ac.nz> wrote:
Chris Angelico wrote:
But since Python _does_ work with dynamic evaluation
(which consequently demands that these kinds of things be expressions
evaluated at compile time), it must by definition be possible to have
side effects.
In most languages, type declarations are not expressions
and aren't evaluated at all in the usual sense, so questions
of evaluation order and side effects just don't apply.
If we were designing a static typing system for Python from
scratch, I would be strongly arguing that type hints shouldn't
be expressions evaluated at run time, because it's such a
poor fit for the intended use. Introspectable by all means,
but evaluated by default, no.
How do you declare that a parameter must be an instance of some class?
Classes are themselves created at run time. Or would your typing
system require that all types be created in some declarable way?
They might be /created/ at runtime, but it's a pretty good bet that the
name A in this declaration:
class A...
is the name of a class. The question in Python, as always, is whether an
A used as the name of a type in a type, is still this same A. And
presumably such a type hint can precede the declaration of A.
In fact the declaration of A might be in a different module from its use
in a type hint, which means that, in the CPython byte-code compiler
anyway, it is not visible at compile-time, when type hints could best be
put to good effect.
Furthermore, both A, and the type-hinting code, might be conditional. So
that on Tuesdays, A is a class, the rest of the week it's the name of a
module.
Python doesn't make things easy.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
