<div dir="ltr"><div>Hi,<br><br></div><div>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.<br><br></div><div>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. <br><br></div><div>Is there any chance to introduce these constructs in the language or is it too small a feature for such a big change?<br><br></div><div>Since we wanted to have contracts in Golang, we implemented a tool that synchronizes the documentation of a function with the function code (<a href="https://github.com/Parquery/gocontracts">https://github.com/Parquery/gocontracts</a>). Maybe this is the easier path to follow in Python as well?<br></div><div><br></div><div>@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:<br><a href="https://github.com/Parquery/icontract/">https://github.com/Parquery/icontract/</a><br></div><div><br></div><div>I also found informative messages on contract breach to be particularly important for fast development and error inspection in the production.<br></div><div><br></div><div>Cheers,<br></div><div>Marko<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 August 2018 at 04:44, Wes Turner <span dir="ltr"><<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">pycontracts may be worth a look.<div><br></div><div><a href="https://andreacensi.github.io/contracts/" target="_blank">https://andreacensi.github.io/<wbr>contracts/</a></div><div><br></div><div>- @contract decorator, annotations, docstrings</div><div><br></div><div>IDK if pycontracts supports runtime parameter validations that involve more than one parameter.</div><div><br></div><div>Inheritance does appear to be supported,</div><div>as are numpy array dimension constraints.</div><div><br></div><div>I can't recall whether the pycontracts expression language precedes MyPy compile-time annotations; both with one syntax really would be great.<div><div class="h5"><br><div><br>On Monday, August 20, 2018, Daniel Moisset <<a href="mailto:dmoisset@machinalis.com" target="_blank">dmoisset@machinalis.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think that annotations were suggested because you could write an expression there without getting evaluated. <div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 August 2018 at 18:49, Marko Ristin-Kaufmann <span dir="ltr"><<a href="mailto:marko.ristin@gmail.com" target="_blank">marko.ristin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi Jonathan and Paul,<div dir="auto">Thank you very much for your suggestions! I will try to contact the author of the PEP.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Marko</div></div><div><div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 16 août 2018 à 12:24, Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 16 Aug 2018 at 10:41, Jonathan Fine <<a href="mailto:jfine2358@gmail.com" rel="noreferrer" target="_blank">jfine2358@gmail.com</a>> wrote:<br>
><br>
> Hi Marko<br>
><br>
> Thank you for introducing yourself, and clearly stating your question.<br>
> That helps us all. You asked:<br>
><br>
> > Could somebody update me on the state of the discussion on this matter?<br>
><br>
> I think bring the existing PEP up to date would be a good starting<br>
> point. Its content hasn't been changed since 2003 (except for PEP-wide<br>
> admin changes. (Recall that Python 3.0 was released in 2008.)<br>
><br>
> <a href="https://www.python.org/dev/peps/pep-0316/" rel="noreferrer noreferrer" target="_blank">https://www.python.org/dev/pep<wbr>s/pep-0316/</a><br>
> <a href="https://github.com/python/peps/commits/master/pep-0316.txt" rel="noreferrer noreferrer" target="_blank">https://github.com/python/peps<wbr>/commits/master/pep-0316.txt</a><br>
><br>
> In fact, revising the PEP might be enough to answer your question.<br>
> What do you think, Marko?<br>
><br>
> Experts: is there a process for revising old PEPs, such as this one?<br>
> Or at least a precedent we could follow (or adapt)?<br>
<br>
I'm not aware of a formal process, but I'd have thought the following<br>
steps would be a reasonable approach:<br>
<br>
1. Review the PEP, and research the discussions that happened at the<br>
time, particularly of interest is why the PEP was deferred.<br>
2. Consider what (if anything) has changed since the original deferral<br>
(which could simply be "time has moved on, people's views may have<br>
changed" but ideally would include a bit more in the way of concrete<br>
motivation).<br>
3. Contact the original PEP author and ask if he is interested in<br>
reopening the discussion, collaborating on a revision, or handing the<br>
PEP over.<br>
4. Start up a discussion here, pointing out the original PEP and<br>
summarising the previous debate and why you want to restart the<br>
discussion. If you're hoping to change the details of the original<br>
PEP, summarise your changes and why you feel they are an improvement<br>
over the original.<br>
<br>
To answer the OP's question more directly:<br>
<br>
> Could somebody update me on the state of the discussion on this matter?<br>
<br>
As far as I am aware, there has been no discussion on this subject<br>
since the PEP 316 discussions which ended up in its deferral. Elazar<br>
mentioned PEP 563, and there *may* have been mention of design by<br>
contract uses in the discussions on that PEP, but you'd have to search<br>
the mailing list archives to confirm that one way or another.<br>
<br>
Hence the suggestions that if you want to restart discussion, reviving<br>
PEP 316 is likely the best approach.<br>
<br>
Paul<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" rel="noreferrer" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div><div dir="ltr"><table style="font-family:"Times New Roman"" cellspacing="0" cellpadding="0" border="0"><tbody><tr valign="top"><td style="display:block;width:60px;margin-right:30px" width="10%"><table width="100%" cellspacing="0" cellpadding="0" border="0"><tbody><tr><td style="display:block;width:120px;height:50px;margin-top:10px;margin-bottom:30px;margin-left:15px" height="150"><a href="https://www.machinalis.com/" style="color:rgb(111,111,111);font-size:12px" target="_blank"><img style="height:auto"></a></td></tr></tbody></table></td><td width="90%"><table width="100%" cellspacing="0" cellpadding="0" border="0"><tbody><tr><td style="padding:0px 0px 0px 20px" valign="top"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr style="font-family:poppins;font-size:14px;font-weight:bold;color:rgb(51,51,51)"><td>Daniel Moisset</td></tr><tr style="font-family:poppins;font-size:12px;text-transform:uppercase;letter-spacing:1px;color:rgb(205,39,66);padding:20px 0px 5px"><td>Technical Leader</td></tr><tr><td style="padding:6px 0px"><table style="width:300px" width="50px" cellspacing="0" cellpadding="0" border="0" height="1px"><tbody><tr><td style="font-size:1px;line-height:1px" bgcolor="#e8e8e8" height="1px"> </td></tr></tbody></table></td></tr><tr><td style="font-family:poppins"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top"><a href="https://goo.gl/maps/pH9BBLgE8dG2" style="color:rgb(111,111,111);font-size:12px" target="_blank"><span>A:   1 Fore St, EC2Y 9DT London</span></a></td></tr></tbody></table></td></tr><tr><td style="font-family:poppins"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top"><a href="tel:+44+7398+827139" style="color:rgb(111,111,111);font-size:12px" target="_blank">P:   +44 7398 827139</a><span style="color:rgb(111,111,111);font-size:12px"></span> <a style="color:rgb(111,111,111);font-size:12px"></a> </td></tr></tbody></table></td></tr><tr><td style="font-family:poppins"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top"><a href="mailto:dmoisset@machinalis.com" style="color:rgb(111,111,111);font-size:12px" target="_blank">M:   dmoisset@machinalis.com</a><span style="color:rgb(111,111,111);font-size:12px">  |  </span> <a style="color:rgb(111,111,111);font-size:12px">S:   dmoisset</a>  </td></tr><tr></tr><tr><td valign="top"></td></tr><tr><td style="padding:10px 0px 0px"><a href="http://www.linkedin.com/company/456525" style="color:rgb(111,111,111);font-size:12px" target="_blank"><img style="height:auto"></a> <a href="http://www.twitter.com/machinalis" style="color:rgb(111,111,111);font-size:12px;padding-left:10px" target="_blank"><img style="height:auto"></a> <a href="http://www.facebook.com/machinalis" style="color:rgb(111,111,111);font-size:12px;padding-left:10px" target="_blank"><img style="height:auto"></a> <a href="https://www.instagram.com/machinalis.life/" style="color:rgb(111,111,111);font-size:12px;padding-left:10px" target="_blank"><img style="height:auto"></a></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table></div></div></div></div></div></div></div></div></div></div></div>
</div>
</blockquote></div></div></div></div>
</blockquote></div><br></div>