[Python-ideas] Optional Static Typing -- the Python Way

[Andrew Barnert]

On Aug 21, 2014, at 9:43, Gregory Salvan <apieum at gmail.com> wrote:

> 
> > I'll admit that I could be off on some of this. It's hard to discuss anything beyond the basics without either getting formal (which I don't think anyone wants) or providing some 
> > realistic examples of where you might want to runtime-check against an annotation (which I think would be very useful, if anyone has one).
> 
> The use case I see is functions composition.
> I think, it's interesting to check at compile time if 2 functions can be composed and at runtime if given arguments are valid.

OK, how about a _concrete_ use case? Function composition is rare enough in Python (we don't even have a compose in functools, much less as an operator or builtin, and how often do you miss it?) that I'm finding it hard to imagine where you'd ever want to, e.g., accept a function that returns Sequence[int] and rcompose it with a function that takes Iterable[Number] and try to validate those compile-time type annotations at runtime.

For that matter, even if you wanted to, how _would_ you validate that something matches Iterable[Number] at runtime, beyond validating that it's iterable?

> 2014-08-21 18:16 GMT+02:00 Andrew Barnert <abarnert at yahoo.com.dmarc.invalid>:
>> On Aug 20, 2014, at 14:57, Antoine Pitrou <antoine at python.org> wrote:
>> 
>> > Le 19/08/2014 20:12, Guido van Rossum a écrit :
>> >>    Hmm, I've been saying this already, but my intuition is that it's a
>> >>    bad idea to conflate *type descriptions* (what this proposal is
>> >>    about) and actual *runtime types* (what ABCs are).
>> >>
>> >>
>> >> But are they? I think the registration mechanism makes it clear that
>> >> they aren't (necessarily) runtime types -- by linking a concrete type
>> >> with an ABC through registration you are pretty clearly stating that the
>> >> ABC *describes* (an aspect of) the concrete class without automatically
>> >> adding any behavior from the ABC to it.
>> >
>> > Hmm... well, they are usable at runtime (if only for isinstance calls :-)). I admit my wording was a bit vague here. But our type descriptions should be able to express more information than ABCs currently do. For example, I don't how you'd express the idea of a "mapping from str to int" using the current Mapping ABC, while retaining the runtime properties of the Mapping class.
>> 
>> Someone (I think Guido, but I can't find it) gave a concrete proposal here (which happens to match how MyPy already works): you make the collections ABCs implement subscripting behavior exactly the way the typing classes do--that is, they just return self. This means that at compile time Mapping[str, int] can be used as a static type hint that a function returns mappings from str to int, while a runtime isinstance check only verifies that the thing in question is a Mapping.
>> 
>> This avoids thorny questions like distinguishing covariant from contravariant contexts at runtime (which I don't think is solvable without a bunch of separate isinstance functions, and a more complicated __subclasshook__ protocol, but I could be wrong).
>> 
>> Also, there's no reason this couldn't be added in 3.5, and then an enhanced runtime meaning given to parameterized ABCs at runtime in 3.6 once someone works out those issues. (So isinstance still ignores the parameters, but iscovariant checks them covariantly, etc.) That wouldn't risk breaking 3.5 code in 3.6.
>> 
>> Also, keep in mind that, just because you _can_ write isinstance(d, Mapping[str, int]) and that might be confusing, that doesn't mean there's any reason you _would_ write that. It will only come up in metaprogramming contexts (e.g., where you're generating a function at runtime to match some type argument). Maybe you could argue that this means the compile-time machinery should be available at runtime, but I don't think you could argue that this means the compile-time types shouldn't be available at runtime.
>> 
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140821/f9cd7c70/attachment.html>