[Python-ideas] Type Hinting Kick-off
jim.baker at python.org
Sat Dec 20 19:29:55 CET 2014
On Sat, Dec 20, 2014 at 11:08 AM, Guido van Rossum <guido at python.org> wrote:
> On Fri, Dec 19, 2014 at 11:59 PM, Steven D'Aprano <steve at pearwood.info>
>> (4) Under "Pragmatics", you say "Don't use dynamic type expressions; use
>> builtins and imported types only. No 'if'." What's the reason for this
>> rule? Will it be enforced by the compiler?
> No, but it will get you on the static checker's nasty list.
For a very good reason - static type checking means we are evaluating types
*statically*, before a program is run. (Otherwise we are doing dynamic type
checking. Python already does a good job of that!)
The Python compiler is completely oblivious to any of this of course -
nothing is changing with it in this proposal for 3.4. Only mypy and other
possible static type checkers and related tools like IDEs will complain. Or
you might be able to get this information at runtime, which can help
support gradual typing.
>> How about this?
>> from condition_is_true import X # str
>> except ImportError:
>> from condition_is_false import X # bytes
> Probably also. In mypy there is limited support for a few specific tests,
> IIRC it has PY3 and PY2 conditions built in. In any case this is all just
> to make the static checker's life easier (since it won't know whether the
> condition is true or false at runtime).
Note that in theory it's possible to define compile-time expressions, as
has been done in C++ 11. (
http://en.wikipedia.org/wiki/Compile_time_function_execution is a good
starting point.) Except for possibly the simplest cases, such as baked-in
support for Py3/Py2, let's not do that.
> (7) You have an example:
>> AnyStr = Var('AnyStr', str, bytes)
>> def longest(a: AnyStr, b: AnyStr) -> AnyStr:
>> Would this be an acceptable syntax?
>> def longest(a:str|bytes, b:str|bytes) -> str|bytes
>> It seems a shame to have to invent a name for something you might only
>> use once or twice.
> That was proposed and rejected (though for Union, which is slightly
> different) because it would require changes to the builtin types to support
> that operator at runtime.
The other thing is AnyStr is a type variable, not a type definition to
shorten writing out types. So AnyStr acts as a constraint that must be
satisfied for the program to type check as valid. (A very simple
constraint.) You can think of it as supporting two possible signatures for
the longest function from the caller's perspective:
def longest(a: str, b: str) -> str
def longest(b: bytes, b: bytes) -> bytes
But not some mix, this would be invalid if the caller of longest try to use
it in this way:
def longest(a: str, b: str) -> bytes
> Please do read up on generic types in mypy.
The linked example of a Stack class demonstrates how the type variable can
work as a constraint for a class, across its methods, similar to what one
might see in Java or Scala.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas