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 https://macropy3.readthedocs.io/en/latest/overview.html): > 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? Cheers, Marko On Tue, 25 Sep 2018 at 06:56, Stephen J. Turnbull < turnbull.stephen...@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@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/
