<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is off topic for discussion of this PEP.</div><div class=""><br class=""></div><div class="">It would require another one (essentially an extension of PEP 484) to get passed for your idea to be standardized. For now, I don't want to distract reviewers from conflating PEP 563 with all the possible wonderful or horrible ways people can potentially extend type hints with. The biggest achievement of PEP 484 is creating a _standard_ syntax for typing in Python that other tools can embrace.</div><div class=""><br class=""></div><div class="">I want to be very explicit that <b class="">in no way should PEP 563 be viewed as a gateway to custom extensions that are going to go against the agreed standard</b>. Further evolution of PEP 484 is possible (as exemplified by PEP 526) but even though PEP 563 does create several opportunities for nicer syntax, this is off topic for the time being.</div><div class=""><br class=""></div><div class="">- Å</div><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 11, 2017, at 2:31 PM, â¨×לעזר⩠<â¨<a href="mailto:elazarg@gmail.com" class="">elazarg@gmail.com</a>â©> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info" class="">steve@pearwood.info</a>> wrote:<br class=""></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 class="">
> I like it. For previous discussion of this idea see here:<br class="">
> <a href="https://mail.python.org/pipermail/python-ideas/2016-September/042527.html" rel="noreferrer" target="_blank" class="">https://mail.python.org/pipermail/python-ideas/2016-September/042527.html</a><br class="">
><br class="">
> I don't see this mentioned in the PEP, but it will also allow (easy)<br class="">
> description of contracts and dependent types.<br class="">
<br class="">
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 class="">
contracts are typically much more powerful than mere type checks, e.g. a<br class="">
contract might state that the argument is float between 0 and 1, </blockquote><div class=""><br class=""></div><div class="">def f(x: float and (0 <= x <= 1)) -> float: ...<br class=""></div><div class=""> <br class=""></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 class="">
least?) three types of contracts: preconditions, which specify the<br class="">
arguments,</blockquote><div class=""><br class=""></div><div class="">Exemplified above</div><div class=""> </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 class=""><br class=""></div><div class="">def f(x: int, y: int) -> ret < y: # ret being an (ugly) convention, unknown to python</div><div class=""> ...</div><div class=""> </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 class=""></blockquote><div class=""><br class=""></div><div class="">class A:</div><div class=""> x: x != 0</div><div class=""> y: y > x</div><div class=""> def foo(self): ...</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">You didn't ask about dependent types, but an example is in order:</div><div class=""><br class=""></div><div class=""> 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 class=""><br class=""></div><div class="">Basically dependent types, like other types, are just a restricted form of contracts.</div><div class=""><br class=""></div><div class="">Elazar</div><div class=""><br class=""></div></div></div>
_______________________________________________<br class="">Python-ideas mailing list<br class=""><a href="mailto:Python-ideas@python.org" class="">Python-ideas@python.org</a><br class="">https://mail.python.org/mailman/listinfo/python-ideas<br class="">Code of Conduct: http://python.org/psf/codeofconduct/<br class=""></div></blockquote></div><br class=""></body></html>