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/