On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano <st...@pearwood.info> wrote:
> On Mon, Sep 11, 2017 at 04:06:14PM +0000, אלעזר wrote: > > I like it. For previous discussion of this idea see here: > > > https://mail.python.org/pipermail/python-ideas/2016-September/042527.html > > > > I don't see this mentioned in the PEP, but it will also allow (easy) > > description of contracts and dependent types. > > How? You may be using a different meaning to the word "contract" than I'm familiar with. I'm thinking about Design By Contract, where the > contracts are typically much more powerful than mere type checks, e.g. a > contract might state that the argument is float between 0 and 1, def f(x: float and (0 <= x <= 1)) -> float: ... > or that the return result is datetime object in the future. There are (at > least?) three types of contracts: preconditions, which specify the > arguments, Exemplified above > postconditions, which specify the return result, def f(x: int, y: int) -> ret < y: # ret being an (ugly) convention, unknown to python ... > and invariants, which specify what doesn't change. > class A: x: x != 0 y: y > x def foo(self): ... Of course I'm not claiming my specific examples are useful or readable. I'm also not claiming anything about the ability to check or enforce it; it's merely about making python more friendly to 3rd party tool support. You didn't ask about dependent types, but an example is in order: def zip(*x: Tuple[List[T], _n]) -> List[Tuple[T, _n]]: ... # _n being a binding occurrence, again not something the interpreter should know Basically dependent types, like other types, are just a restricted form of contracts. Elazar
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
