Hi, Stephen J. Turnbull wrote:
> You can't weaken the > contracts for iparent.recontract as far as I can see in a decorator- > based contract library Of course you can weaken the contracts for iparent.recontract with a decorator-based contract library. From my first message: > The features include: > ... > * inheritance of the contracts (with strengthening/weakening) > ... > Please also have a look at the readme on https://github.com/Parquery/icontract/, Section "Inheritance". Chris Barker wrote: > 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. I absolutely agree. In my first message I wrote: > 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. > and in my second message (before yours), I wrote: > 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 (*e.g., *were there any problems with the > toggling granularity? readability? maintainability?). Then we decide how to > proceed. > Stefane Fermigier wrote: > 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). > 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. > 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. > Thanks, I'm looking forward to hearing your experience! I contacted the authors of dpcontracts, but there is still no clear plan of action how to merge icontract and dpcontracts (see https://github.com/deadpixi/contracts/issues/15). Other libraries seem either unmaintained or not applicable except for single-argument checks and involve custom syntax (like https://pypi.org/project/PyContracts/; 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). 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*. *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? > 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. > I agree. Nathaniel Smith wrote: > In your position, I wouldn't be talking to the core devs; I'd be > writing blog posts to proselytize the advantages of contracts, working > with popular projects that are interested in adopting them, writing > case studies, going to meetups, submitting talks to pycons, that sort > of thing. If you want contracts to become a widely-used thing, you > have to convince people to use them. The core team doesn't have a > magic wand that can short-circuit that process. > 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). 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. Cheers, Marko
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
