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

Marko Ristin-Kaufmann marko.ristin at gmail.com
Tue Sep 25 02:18:49 EDT 2018

Hi Steve,
Thanks a lot for pointing us to macropy -- I was not aware of the library,
it looks very interesting!

Do you have any experience how macropy fit with current IDEs and static
linters (pylint, mypy)? I fired up pylint and mypy on the sample code from
their web site, played a bit with it and it seems that they go along well.

I'm also a bit worried how macropy would work out in the libraries
published to pypi -- imagine if many people start using contracts.
Suddenly, all these libraries would not only depend on a contract library
but on a macro library as well. Is that something we should care about?
Potential dependency hell? (I already have a bad feeling about making
icontract depend on asttokens and considerin-lining asttokens into
icontract particularly for that reason).

I'm also worried about this one (from

> Note that this means *you cannot use macros in a file that is run
> directly*, as it will not be passed through the import hooks.

That would make contracts unusable in any stand-alone script, right?


On Tue, 25 Sep 2018 at 06:56, Stephen J. Turnbull <
turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:

> Barry Scott writes:
>  > > @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?
>  >
>  > The lambda smells of internals that I should not have to care about
>  > being exposed.
>  > So -1 on lambda being required.
> If you want to get rid of the lambda you can use strings and then
> 'eval' them in the condition.  Adds overhead.
> If you want to avoid the extra runtime overhead of parsing
> expressions, it might be nice to prototype with MacroPy.  This should
> also allow eliminating the lambda by folding it into the macro (I
> haven't used MacroPy but it got really good reviews by fans of that
> kind of thing).  It would be possible to avoid decorator syntax if you
> want to with this implementation.
> I'm not sure that DbC is enough of a fit for Python that it's worth
> changing syntax to enable nice syntax natively, but detailed reports
> on a whole library (as long as it's not tiny) using DbC with a nice
> syntax (MacroPy would be cleaner, but I think it would be easy to "see
> through" the quoted conditions in an eval-based implementation) would
> go a long way to making me sit up and take notice.  (I'm not
> influential enough to care about, but I suspect some committers would
> be impressed too.  YMMV)
> Steve
> _______________________________________________
> 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/714635cd/attachment-0001.html>

More information about the Python-ideas mailing list