Hi Abe, I've been pulling a lot of ideas from the recent discussion on design by > contract (DBC), the elegance and drawbacks > <https://bemusement.org/doctests-arent-code> of doctests > <https://docs.python.org/3/library/doctest.html>, and the amazing talk > <https://www.youtube.com/watch?v=MYucYon2-lk> given by Hillel Wayne at > this year's PyCon entitled "Beyond Unit Tests: Taking your Tests to the > Next Level". >
Have you looked at the recent discussions regarding design-by-contract on this list ( https://groups.google.com/forum/m/#!topic/python-ideas/JtMgpSyODTU and the following forked threads)? You might want to have a look at static checking techniques such as abstract interpretation. I hope to be able to work on such a tool for Python in some two years from now. We can stay in touch if you are interested. Re decorators: to my own surprise, using decorators in a larger code base is completely practical including the readability and maintenance of the code. It's neither that ugly nor problematic as it might seem at first look. We use our https://github.com/Parquery/icontract at the company. Most of the design choices come from practical issues we faced -- so you might want to read the doc even if you don't plant to use the library. Some of the aspects we still haven't figured out are: how to approach multi-threading (locking around the whole function with an additional decorator?) and granularity of contract switches (right now we use always/optimized, production/non-optimized and teating/slow, but it seems that a larger system requires finer categories). Cheers Marko
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
