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 <dmois...@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.ris...@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.mo...@gmail.com> a écrit : >> >>> On Thu, 16 Aug 2018 at 10:41, Jonathan Fine <jfine2...@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@python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@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: dmois...@machinalis.com <dmois...@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/> >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
