[Python-ideas] Why is design-by-contracts not widely adopted?
marko.ristin at gmail.com
Tue Sep 25 02:18:49 EDT 2018
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)
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas