[Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

[אלעזר]

On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano <steve at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170911/53c2ea17/attachment.html>