[Python-ideas] [Brainstorm] Testing with Documented ABCs

[Marko Ristin-Kaufmann]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181128/756585ae/attachment.html>