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

[Abe Dillon]

Marko, I have a few thoughts that might improve icontract.
First, multiple clauses per decorator:

@pre(
    *lambda* x: x >= 0,
    *lambda* y: y >= 0,
    *lambda* width: width >= 0,
    *lambda* height: height >= 0,
    *lambda* x, width, img: x + width <= width_of(img),
    *lambda* y, height, img: y + height <= height_of(img))
@post(
    *lambda* self: (self.x, self.y) in self,
    *lambda* self: (self.x+self.width-1, self.y+self.height-1) in self,
    *lambda* self: (self.x+self.width, self.y+self.height) not in self)
*def* __init__(self, img: np.ndarray, x: int, y: int, width: int, height:
int) -> None:
    self.img = img[y : y+height, x : x+width].copy()
    self.x = x
    self.y = y
    self.width = width
    self.height = height

*def* __contains__(self, pt: Tuple[int, int]) -> bool:
    x, y = pt
    return (self.x <= x < self.x + self.width) and (self.y <= y < self.y +
self.height)


You might be able to get away with some magic by decorating a method just
to flag it as using contracts:


@contract  # <- does byte-code and/or AST voodoo
*def* __init__(self, img: np.ndarray, x: int, y: int, width: int, height:
int) -> None:
    pre(x >= 0,
        y >= 0,
        width >= 0,
        height >= 0,
        x + width <= width_of(img),
        y + height <= height_of(img))

    # this would probably be declared at the class level
    inv(*lambda* self: (self.x, self.y) in self,
        *lambda* self: (self.x+self.width-1, self.y+self.height-1) in self,
        *lambda* self: (self.x+self.width, self.y+self.height) not in self)

    self.img = img[y : y+height, x : x+width].copy()
    self.x = x
    self.y = y
    self.width = width
    self.height = height

That might be super tricky to implement, but it saves you some lambda
noise. Also, I saw a forked thread in which you were considering some sort
of transpiler  with similar syntax to the above example. That also works.
Another thing to consider is that the role of descriptors
<https://www.smallsurething.com/python-descriptors-made-simple/> overlaps
some with the role of invariants. I don't know what to do with that
knowledge, but it seems like it might be useful.

Anyway, I hope those half-baked thoughts have *some* value...

On Wed, Nov 28, 2018 at 1:12 AM Marko Ristin-Kaufmann <
marko.ristin at gmail.com> wrote:

> 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/76f2bbde/attachment-0001.html>