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

[Gregory Salvan]

> 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.


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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140821/14b51e37/attachment-0001.html>