[Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

[Steven D'Aprano]

On Sun, Sep 30, 2018 at 12:17:25PM +1000, Chris Angelico wrote:
> On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano <steve at pearwood.info> wrote:
> > This discussion is for those of us who would like to include DbC in our
> > projects but don't like existing solutions. C++ being designed with a
> > shovel is not relevant.
> >
> > (Except in the sense that we should always be careful about piling on
> > feature upon feature into Python.)
> 
> And as such, I do not want to see dedicated syntax for no purpose
> other than contracts.

That's a reasonable objection, except that contracts are a BIG purpose.

Would you object to dedicated syntax for object oriented programming? 
(Classes and methods.) I hope not. Imagine if OOP in Python was limited 
to an API like this:


MyClass = type(name="MyClass", parent=object)
MyClass.add_method(__init__=lambda self, arg: setattr(self, "arg", arg))
MyClass.add_method(__str__=lambda self: "MyClass(%r)" % (self.arg,))
MyClass.add_method(spam=lambda self, x, y: (self.arg + x)/y)
MyClass.add_method(eggs=lambda self, x, y: self.arg*x - y)
MyClass.add_member(cheese='Cheddar')
MyClass.add_member(aardvark=None)


That's the situation we're in right now for contracts. It sucks and 
blows at the same time. Syntax matters, and sometimes without the right 
syntax, certain techniques and methodologies aren't practical.

I know that adding syntax is a big step, and should be considered a last 
resort for when a library or even a built-in won't work. But adding 
contracts isn't a small benefit. Its not a magic bullet, nobody says 
that, but I would say that contracts as a feature is *much* bigger and 
more important than (say) docstrings, and we have dedicated syntax for 
docstrings.


> What I'm interested in is (a) whether something
> can and should be added to the stdlib, and (b) whether some specific
> (and probably small) aspect of it could benefit from language support.
> As a parallel example, consider type hints. The language has ZERO
> support for special syntax for a language of types.

That's a weird use of the word "ZERO" :-)

    def spam(x: int) -> float:
        y: int

I count three special syntax forms for a language of types:

- parameter type hints;
- return type hints;
- variable type hints.


(Yes, I'm aware that *technically* we can put anything we like in the 
hints, they don't have to be used as type hints, but Guido has made it 
clear that such uses are definitely of second-rate importance and only 
grudgingly supported.)


> What you have is
> simple, straight-forward names like "List", and the normal behaviours
> that we already can do such as subscripting. There is language
> support, however, for attaching expressions to functions and their
> arguments.

Your point is taken that there is no separate syntax for referring to 
the types *themselves*, but then there's no need for such. int is int, 
whether you refer to the class "int" or the static type "int".


 
> At the moment, I'm seeing decorator-based contracts as a clunky
> version of unit tests.

Contracts are not unit tests.

Contracts and unit tests are complementary, and overlap somewhat, but 
they are the same. Unit tests only test the canned values you write in 
you tests. Contracts test real data you pass to your application.




-- 
Steve