[Python-ideas] Pre-conditions and post-conditions

[Wes Turner]

pycontracts may be worth a look.

https://andreacensi.github.io/contracts/

- @contract decorator, annotations, docstrings

IDK if pycontracts supports runtime parameter validations that involve more
than one parameter.

Inheritance does appear to be supported,
as are numpy array dimension constraints.

I can't recall whether the pycontracts expression language precedes MyPy
compile-time annotations; both with one syntax really would be great.

On Monday, August 20, 2018, Daniel Moisset <dmoisset at machinalis.com> wrote:

> I think that annotations were suggested because you could write an
> expression there without getting evaluated.
>
> I've thought about this problem many times in the past (as a Python dev
> with a long history working in Eiffel too).... For me one of the crucial
> issue that is hard to translate into the python model is that the
> assertions (say, a function precondition) are not conceptually part of the
> function itself, but the interface of the class. The "natural" python ways
> of attaching these assertions somehow to the function object do not work
> when you also use inheritance, because when you override a method the new
> function object clobbers the previous one. I've experimented at some point
> on how to put them in classes (and doing metaclass or __getattribute__
> tricks) but nothing convinced me). In general, the way that python puts
> method call and inheritance semantic in a specific layout of runtime
> objects (which in general is really clever) seems to be a bit alien to the
> DbC idea where the asbtraction/interface of the class is conceptually
> separate and has independent information wrt to the runtime objects.
>
>
> On 16 August 2018 at 18:49, Marko Ristin-Kaufmann <marko.ristin at gmail.com>
> wrote:
>
>> Hi Jonathan and Paul,
>> Thank you very much for your suggestions! I will try to contact the
>> author of the PEP.
>>
>> Let me clarify a bit a potential misunderstanding. Please mind that
>> contracts are not tied to individual variables, but to expressions. Think
>> of it as defining a lambda which takes as input all the arguments of the
>> function (and a result variable in case of post-conditions) which always
>> needs to evaluate to True.
>>
>> Cheers,
>> Marko
>>
>> Le jeu. 16 août 2018 à 12:24, Paul Moore <p.f.moore at gmail.com> a écrit :
>>
>>> On Thu, 16 Aug 2018 at 10:41, Jonathan Fine <jfine2358 at gmail.com> wrote:
>>> >
>>> > Hi Marko
>>> >
>>> > Thank you for introducing yourself, and clearly stating your question.
>>> > That helps us all. You asked:
>>> >
>>> > > Could somebody update me on the state of the discussion on this
>>> matter?
>>> >
>>> > I think bring the existing PEP up to date would be a good starting
>>> > point. Its content hasn't been changed since 2003 (except for PEP-wide
>>> > admin changes. (Recall that Python 3.0 was released in 2008.)
>>> >
>>> > https://www.python.org/dev/peps/pep-0316/
>>> > https://github.com/python/peps/commits/master/pep-0316.txt
>>> >
>>> > In fact, revising the PEP might be enough to answer your question.
>>> > What do you think, Marko?
>>> >
>>> > Experts: is there a process for revising old PEPs, such as this one?
>>> > Or at least a precedent we could follow (or adapt)?
>>>
>>> I'm not aware of a formal process, but I'd have thought the following
>>> steps would be a reasonable approach:
>>>
>>> 1. Review the PEP, and research the discussions that happened at the
>>> time, particularly of interest is why the PEP was deferred.
>>> 2. Consider what (if anything) has changed since the original deferral
>>> (which could simply be "time has moved on, people's views may have
>>> changed" but ideally would include a bit more in the way of concrete
>>> motivation).
>>> 3. Contact the original PEP author and ask if he is interested in
>>> reopening the discussion, collaborating on a revision, or handing the
>>> PEP over.
>>> 4. Start up a discussion here, pointing out the original PEP and
>>> summarising the previous debate and why you want to restart the
>>> discussion. If you're hoping to change the details of the original
>>> PEP, summarise your changes and why you feel they are an improvement
>>> over the original.
>>>
>>> To answer the OP's question more directly:
>>>
>>> > Could somebody update me on the state of the discussion on this matter?
>>>
>>> As far as I am aware, there has been no discussion on this subject
>>> since the PEP 316 discussions which ended up in its deferral. Elazar
>>> mentioned PEP 563, and there *may* have been mention of design by
>>> contract uses in the discussions on that PEP, but you'd have to search
>>> the mailing list archives to confirm that one way or another.
>>>
>>> Hence the suggestions that if you want to restart discussion, reviving
>>> PEP 316 is likely the best approach.
>>>
>>> Paul
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
>
> --
> <https://www.machinalis.com/>
> Daniel Moisset
> Technical Leader
>
> A:   1 Fore St, EC2Y 9DT London <https://goo.gl/maps/pH9BBLgE8dG2>
> P:   +44 7398 827139 <+44+7398+827139>
> M:   dmoisset at machinalis.com <dmoisset at machinalis.com>  |   S:   dmoisset
>
> <http://www.linkedin.com/company/456525>
> <http://www.twitter.com/machinalis>  <http://www.facebook.com/machinalis>
> <https://www.instagram.com/machinalis.life/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180820/b7cb498f/attachment.html>