[Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft
אלעזר
elazarg at gmail.com
Mon Sep 11 14:31:46 EDT 2017
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>
More information about the Python-ideas
mailing list