This is off topic for discussion of this PEP. 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.
I want to be very explicit that in no way should PEP 563 be viewed as a gateway to custom extensions that are going to go against the agreed standard. 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. - Ł > On Sep 11, 2017, at 2:31 PM, אלעזר <elaz...@gmail.com> wrote: > > > > On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano <st...@pearwood.info > <mailto: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 > > <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/
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
