[Python-ideas] DBC (Re: Explicit variable capture list)

[Michael Selik]

On Mon, Jan 25, 2016 at 7:24 PM David Mertz <mertz at gnosis.cx> wrote:

> Just curious, Michael, what would you like the Python syntax version to
> look like if you *can* do whatever metaclass or stack hackery that's
> needed?  I'm a little confused when you mention a decorator and a context
> manager in the same sentence since those would seem like different
> approaches.
>

Now that you mention it, that does seem weird. Initially the pattern of
trying to factor out a setup/cleanup feels like a context manager. But we
also need to capture the function arguments and return value. So that feels
like a decorator.

I started by implementing an abstract base class Contract that sets up the
require/ensure behavior. One inherits and overrides to implement a
particular contract. The overridden require/ensure functions would receive
the arguments/result of a decorated function.

    class StayPositive(Contract):
        def require(self, *args, **kwargs):
            assert sum(args + list(kwargs.values())
        def ensure(self, result, *args, **kwargs):
            # ensure receives not only the result, but also same argument
objs
            assert sum(result)

    @StayPositive
    def foo(i + am + happy):
        return i + am + happy

One thing I like here is that the require/ensure doesn't clutter the
function definition with awkward decorator parameters. The contract terms
are completely separate. This does put the burden on wisely naming the
contract subclass name.

The combination of decorator and context manager was unnecessary. The
internals of my Contract base class included an awkward ``with self:``. If
I were to refactor, I'd separate out a context manager helper from the
decorator object.

Seeing some of the stubs folks have written makes me think this ends with
exec-ing a template a la namedtuple.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160127/7600dcc0/attachment.html>