<div dir="ltr"><div><div><div><div><div>> 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,...<br><br></div>True, explicit composition is actually uncommon practice in python, whereas there are lots of libs: toolz, funcy, fn.py, Pymonads....<br></div><div>Note that composition can be implicit: f(g(x)) <br>
</div><div><br>Using mypy syntax was originally pushed with a presentation about what python can learn from FP.<br>Personnally, I consider FP types have a different meaning than OO types, I feel them more as a way to describe programs flows (by func de/composition) and that's something I find really usefull in some cases (mainly for parsing and parallel computing). <br>
That's what I expect python would learn from FP and why I'm delighted about this proposition. (my opinion doesn't matter but +1000 for the proposition :)<br></div><br></div>> and, how often do you miss it ? <br>
sufficiently to have written my own tool, which I started to extract from a project few days before Guido announces his mypy proposal. (in development but usable: <a href="https://github.com/apieum/lawvere">https://github.com/apieum/lawvere</a> )<br>
<br><br>> 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 <br>> takes
Iterable[Number] and try to validate those compile-time type annotations
at runtime.<br></div><div><br>I've not such cases in mind, I thought more of these ones:<br></div><br><pre class="">from functools import singledispatch
<br>@singledispatch<br>def div1000(a: intexcept0) -> int:<br></pre><pre class=""> return 1000 / a<br><br></pre><pre class="">@div1000.register<br>def divby0(a: Just(0)):<br></pre><pre class=""> log('something')...<br>
</pre><pre class=""><br></pre>In this case it's interesting to know if for ex. div1000 can be composed with sub500... when compiling<br></div><div>and if it's 0 or not at runtime. <br>(OK the example is simple and you can use a condition inside div1000 but you can have more complex cases of this type or want to use divby0 elsewhere)<br>
</div><div><div><div><br><div><div><div><div><br></div><div>> 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?</div><br>I'm not sure to understand what you are asking. <br>I see Iterable[Number] as a kind of type constructor (like Just(0)) even if it's cached. I would probably check it at runtime with isinstance.<br>
</div><div><br><div class="gmail_extra">
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-21 20:36 GMT+02:00 Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto"><div class=""><div>On Aug 21, 2014, at 9:43, Gregory Salvan <<a href="mailto:apieum@gmail.com" target="_blank">apieum@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr">
<br>
> 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 <br>> realistic examples of where you
might want to runtime-check against an annotation (which I think would
be very useful, if anyone has one).<div class="gmail_extra"><br></div><div class="gmail_extra">The use case I see is functions composition.<br>I think, it's interesting to check at compile time if 2 functions can be composed and at runtime if given arguments are valid.<br>
</div></div></div></blockquote><div><br></div></div>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.<div>
<div><br></div><div>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?</div><div><div class="h5"><div><br><blockquote type="cite">
<div><div dir="ltr"><div class="gmail_extra">
</div><div class="gmail_extra"><div class="gmail_quote">2014-08-21 18:16 GMT+02:00 Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com.dmarc.invalid" target="_blank">abarnert@yahoo.com.dmarc.invalid</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Aug 20, 2014, at 14:57, Antoine Pitrou <<a href="mailto:antoine@python.org" target="_blank">antoine@python.org</a>> wrote:<br>
<br>
> Le 19/08/2014 20:12, Guido van Rossum a écrit :<br>
>> Hmm, I've been saying this already, but my intuition is that it's a<br>
>> bad idea to conflate *type descriptions* (what this proposal is<br>
>> about) and actual *runtime types* (what ABCs are).<br>
>><br>
>><br>
>> But are they? I think the registration mechanism makes it clear that<br>
>> they aren't (necessarily) runtime types -- by linking a concrete type<br>
>> with an ABC through registration you are pretty clearly stating that the<br>
>> ABC *describes* (an aspect of) the concrete class without automatically<br>
>> adding any behavior from the ABC to it.<br>
><br>
> 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.<br>
<br>
</div>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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
<div><div>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a></div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Python-ideas mailing list</span><br><span><a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a></span><br>
<span><a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a></span><br><span>Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a></span></div>
</blockquote></div></div></div></div></div></blockquote></div><br></div></div></div></div></div></div></div></div>