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

Tue Aug 21 03:06:54 EDT 2018

Hi,

I had a look at the messages related to the PEP in question (PEP 316) in
the archive. As far as I can tell, the main objection is that you can
achieve contracts by implementing it with decorators.

I think that these objections miss what actually Daniel Moisset wrote in
his message: contracts are more than pre- and post-condition checks on a
function. The inheritance of decorators does not imply just inheriting the
pre- and post-conditions, but also relaxing and tightening them
(represented by "require else" and "ensure then" in Eiffel). If this is to
be used effectively in practice with little overhead then we would either
need to introduce new syntax to the language or make the compiler improve
the byte code on the fly.

Is there any chance to introduce these constructs in the language or is it
too small a feature for such a big change?

Since we wanted to have contracts in Golang, we implemented a tool that
synchronizes the documentation of a function with the function code (
https://github.com/Parquery/gocontracts). Maybe this is the easier path to
follow in Python as well?

@Wes Turner: thanks for pointing to pycontracts. I'm aware of the library.
It implements only contracts based on a single property. We found that
limiting and rolled out our own solution that suited us much better:
https://github.com/Parquery/icontract/

I also found informative messages on contract breach to be particularly
important for fast development and error inspection in the production.

Cheers,
Marko

On 21 August 2018 at 04:44, Wes Turner <wes.turner at gmail.com> wrote:

> 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/20180821/db155bdd/attachment-0001.html>