[Python-ideas] Why is design-by-contracts not widely adopted?

[Angus Hollands]

Hi Mario,
yes I'd pass in some kind of 'old' object as a proxy to the old object
state.

My demo can handle function calls, unless they themselves ultimately call
something which can't be proxies e.g is instance (which delegates to the
test class, not the instance), or boolean evaluation of some expression
(e.g an if block). I don't think that this is awful - contracts should
probably be fairly concise while expressive - but definitely non-ideal.

I haven't really time to work on this at the moment; I admit, it was a
specific problem of interest, rather than a domain I have much experience
with. In fact, it was probably an excuse to overload all of the operators
on an object!

Kind regards,
Angus

On Mon, 24 Sep 2018, 20:09 Marko Ristin-Kaufmann, <marko.ristin at gmail.com>
wrote:

> Hi Barry,
> I think the main issue with pyffel is that it can not support function
> calls in general. If I understood it right, and Angus please correct me,
> you would need to wrap every function that you would call from within the
> contract.
>
> But the syntax is much nicer than icontract or dpcontracts (see these
> packages on pypi). What if we renamed "args" argument and "old" argument in
> those libraries to just "a" and "o", respectively? Maybe that gives
> readable code without too much noise:
>
> @requires(lambda self, a, o: self.sum == o.sum - a.amount)
> def withdraw(amount: int) -> None:
>     ...
>
> There is this lambda keyword in front, but it's not too bad?
>
> I'll try to contact dpcontracts maintainers. Maybe it's possible to at
> least merge a couple of libraries into one and make it a de facto standard.
> @Agnus, would you also like to join the effort?
>
> Cheers,
> Marko
>
>
>
>
>
> Le lun. 24 sept. 2018 à 19:57, Barry Scott <barry at barrys-emacs.org> a
> écrit :
>
>>
>>
>> On 23 Sep 2018, at 11:13, Angus Hollands <goosey15 at gmail.com> wrote:
>>
>> Hi Marko,
>>
>> I think there are several ways to approach this problem, though am not
>> weighing in on whether DbC is a good thing in Python. I wrote a simple
>> implementation of DbC which is currently a run-time checker. You could,
>> with the appropriate tooling, validate statically too (as with all
>> approaches). In my approach, I use a “proxy” object to allow the contract
>> code to be defined at function definition time. It does mean that some
>> things are not as pretty as one would like - anything that cannot be hooked
>> into with magic methods i.e isinstance, but I think this is acceptable
>> as it makes features like old easier. Also, one hopes that it encourages
>> simpler contract checks as a side-effect. Feel free to take a look -
>> https://github.com/agoose77/pyffel
>> It is by no means well written, but a fun PoC nonetheless.
>>
>> This is an interesting PoC, nice work! I like that its easy to read the
>> tests.
>>
>> Given a library like this the need to build DbC into python seems
>> unnecessary.
>>
>> What do other people think?
>>
>> Barry
>>
>>
>>
>> Regards,
>> Angus
>> ​
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180925/6050dde8/attachment-0001.html>