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/
