<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<br><br></div><div>Stephen J. Turnbull wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You can't weaken the<br>
contracts for iparent.recontract as far as I can see in a decorator-<br>
based contract library</blockquote><div><br></div><div>Of course you can weaken the contracts for iparent.recontract with a decorator-based contract library. From my first message:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>The features include:<br>...<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* inheritance of the contracts (with strengthening/weakening)<br>...<br></blockquote><div><br></div><div>Please also have a look at the readme on <a href="https://github.com/Parquery/icontract/">https://github.com/Parquery/icontract/</a>, Section "Inheritance".<br><br></div><div>Chris Barker wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">However, I'm not sure it's anywhere near time to actually do that -- 
before we get there, there needs to be a pretty good community of folks 
using icontract (or maybe something else?) and ideally some interest 
from a core developer or two.</blockquote></div><div><br></div><div>I absolutely agree. In my first message I wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Before we organize a collective to write a proposal to standardize the 
library, I would suggest that a couple of other interested teams adopt 
icontract, apply it to their code bases and report their experiences on 
this mail list. I hope that 2-3 reports would be insightful enough to 
either convince other people that contracts in python are worth 
standardizing (and highlight missing features yet to be implemented) or 
provide solid material to discard the endeavor at the current moment.<br></blockquote><div><br></div><div>and in my second message (before yours), I wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My conclusion is at this point is that the best course of action would 
be that other teams pick up a contract library (now that there is at 
least icontract library with a full feature set for design-by-contract 
akin to Eiffel and other languages), and present us how they use 
contracts and what problems they were facing (<i>e.g., </i>were there any problems with the toggling granularity? readability? maintainability?). Then we decide how to proceed. <br></blockquote></div></div><div> <br></div><div>Stefane Fermigier wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>1) Just as with with PEP 484, we could distinguish between contract
 specification and checking. To achieve some of the goals that you 
state, we need to standardise the way people would state contracts in 
their code (and provide a small implementation in the stdlib, similar to
 the typing module), but how these contracts are verified (at runtime or
 statically) or leveraged in the documentation are left to third party 
projects (similar to mypy & al).</div></blockquote><div><br></div><div>This is a great idea -- though I'm not sure how it could be implemented other than already specifying the implementation (i.e. how the contracts are verified). If you have some time, could you elaborate a bit how this might work? I'm suffering from tunnel vision at this point after implementing the library.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div>2) 
Building momentum is paramount. First, since there are many contracts 
libraries out there, some dating more than 15 years (ex: PyDBC), we'd 
need to build consensus between the people who wrote and use these 
libraries. And of course, get feedback from people who use this approach
 on significant projects. I'm willing to try your library on one of my 
projects.</div></blockquote><div><br></div><div>Thanks, I'm looking forward to hearing your experience! <br><br>I contacted the authors of dpcontracts, but there is still no clear plan of action how to merge icontract and dpcontracts (see <a href="https://github.com/deadpixi/contracts/issues/15">https://github.com/deadpixi/contracts/issues/15</a>). Other libraries seem either unmaintained or not applicable except for single-argument checks and involve custom syntax (like <a href="https://pypi.org/project/PyContracts/">https://pypi.org/project/PyContracts/</a>; I only played a bit with PyContracts, so it would be great if anybody could tell their experience with it in a larger code base).<br><br></div><div>We found that all the present libraries were far from usable for a larger code base (so we rolled out our own). To the best of our knowledge, none could deal with inheritance properly (weakening/strengthening) and you always had to write out the condition along the lambda function (unless the code was parsed from the documentation which increases the import time significantly even if you want to disable some of the contracts). As others already mentioned in the previous discussion, part of the reason for not adopting DbC was the lack of tools. I'm not saying that icontract should be that standard tool -- not at all! We need to first find out what such standard tool would need to fulfill<i>. </i>Assuming that we don't make language changes, what would we like the standard contract library to look like? What features should it have? What is too much of a niche to be left out? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>3) Having contracts for most of the 
stdlib would be a worthy goal (for contracts users) but, as noted by 
some, would come with some speed issues. And of course, would represent a
 multi-year effort. Hopefully your project (i.e. standardising a 
library, but not "contracting" the stdlib) would still be valuable if 
this never happen.</div></blockquote><div><br></div><div>I agree.<br><br></div><div>Nathaniel Smith wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In your position, I wouldn't be talking to the core devs; I'd be<br>
writing blog posts to proselytize the advantages of contracts, working<br>
with popular projects that are interested in adopting them, writing<br>
case studies, going to meetups, submitting talks to pycons, that sort<br>
of thing. If you want contracts to become a widely-used thing, you<br>
have to convince people to use them. The core team doesn't have a<br>
magic wand that can short-circuit that process.<span class="gmail-im"><br></span></blockquote></div><div><br></div><div>I thought python-ideas is an open list to generally discuss ideas, not the core dev list (isn't that python-dev)? That's why I wrote here (after being forwarded from python-dev list).<br><br></div><div>I agree that these efforts you mention would be worthwhile. Implementation of a (prototype) library and participating in the discussions on this mail list are the maximum effort I can put up at the moment. Maybe in 2019 I could manage to go to the local Python summit.<br></div><div><br></div><div>Cheers,<br></div><div>Marko<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>