<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Sep 11, 2017 at 04:06:14PM +0000, ×לעזר wrote:<br>
> I like it. For previous discussion of this idea see here:<br>
> <a href="https://mail.python.org/pipermail/python-ideas/2016-September/042527.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/python-ideas/2016-September/042527.html</a><br>
><br>
> I don't see this mentioned in the PEP, but it will also allow (easy)<br>
> description of contracts and dependent types.<br>
<br>
How? You may be using a different meaning to the word "contract" than I'm</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
familiar with. I'm thinking about Design By Contract, where the<br>
contracts are typically much more powerful than mere type checks, e.g. a<br>
contract might state that the argument is float between 0 and 1, </blockquote><div><br></div><div>def f(x: float and (0 <= x <= 1)) -> float: ...<br></div><div>Â <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">or that the return result is datetime object in the future. There are (at<br>
least?) three types of contracts: preconditions, which specify the<br>
arguments,</blockquote><div><br></div><div>Exemplified above</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> postconditions, which specify the return result, </blockquote><div><br></div><div>def f(x: int, y: int) -> ret < y:   # ret being an (ugly) convention, unknown to python</div><div>  ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and invariants, which specify what doesn't change.<br></blockquote><div><br></div><div>class A:</div><div>  x: x != 0</div><div>  y: y > x</div><div>  def foo(self): ...</div><div><br></div><div>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.</div><div><br></div><div>You didn't ask about dependent types, but an example is in order:</div><div><br></div><div>  def zip(*x: Tuple[List[T], _n]) -> List[Tuple[T, _n]]: ...   # _n being a binding occurrence, again not something the interpreter should know</div><div><br></div><div>Basically dependent types, like other types, are just a restricted form of contracts.</div><div><br></div><div>Elazar</div><div><br></div></div></div>