<div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><div><div>Hi Steve,<br></div>Thanks a lot for pointing us to macropy -- I was not aware of the library, it looks very interesting!<br><br></div></div>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.<br><br>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).<br><br></div><div>I'm also worried about this one (from <a href="https://macropy3.readthedocs.io/en/latest/overview.html">https://macropy3.readthedocs.io/en/latest/overview.html</a>):<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that this means <strong>you cannot use macros in a file that is run
directly</strong>, as it will not be passed through the import hooks.</blockquote><div><br></div><div>That would make contracts unusable in any stand-alone script, right?<br><br></div><div>Cheers, <br></div><div>Marko<br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 25 Sep 2018 at 06:56, Stephen J. Turnbull <<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp">turnbull.stephen.fw@u.tsukuba.ac.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Barry Scott writes:<br>
<br>
 > > @requires(lambda self, a, o: self.sum == o.sum - a.amount)<br>
 > > def withdraw(amount: int) -> None:<br>
 > >     ...<br>
 > > <br>
 > > There is this lambda keyword in front, but it's not too bad?<br>
 > <br>
 > The lambda smells of internals that I should not have to care about<br>
 > being exposed.<br>
 > So -1 on lambda being required.<br>
<br>
If you want to get rid of the lambda you can use strings and then<br>
'eval' them in the condition.  Adds overhead.<br>
<br>
If you want to avoid the extra runtime overhead of parsing<br>
expressions, it might be nice to prototype with MacroPy.  This should<br>
also allow eliminating the lambda by folding it into the macro (I<br>
haven't used MacroPy but it got really good reviews by fans of that<br>
kind of thing).  It would be possible to avoid decorator syntax if you<br>
want to with this implementation.<br>
<br>
I'm not sure that DbC is enough of a fit for Python that it's worth<br>
changing syntax to enable nice syntax natively, but detailed reports<br>
on a whole library (as long as it's not tiny) using DbC with a nice<br>
syntax (MacroPy would be cleaner, but I think it would be easy to "see<br>
through" the quoted conditions in an eval-based implementation) would<br>
go a long way to making me sit up and take notice.  (I'm not<br>
influential enough to care about, but I suspect some committers would<br>
be impressed too.  YMMV)<br>
<br>
Steve<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>