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

[Gregory Salvan]

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

True, explicit composition is actually uncommon practice in python, whereas
there are lots of libs: toolz, funcy, fn.py, Pymonads....
Note that composition can be implicit: f(g(x))

Using mypy syntax was originally pushed with a presentation about what
python can learn from FP.
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).
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
:)

> and, how often do you miss it ?
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: https://github.com/apieum/lawvere )


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

I've not such cases in mind, I thought more of these ones:

from functools import singledispatch
@singledispatch
def div1000(a: intexcept0) -> int:

  return 1000 / a

@div1000.register
def divby0(a: Just(0)):

  log('something')...


In this case it's interesting to know if for ex. div1000 can be composed
with sub500... when compiling
and if it's 0 or not at runtime.
(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)


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

I'm not sure to understand what you are asking.
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.



2014-08-21 20:36 GMT+02:00 Andrew Barnert <abarnert at yahoo.com>:

> 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/9eaa7395/attachment.html>