[Python-ideas] Why is design-by-contracts not widely adopted?

[Stephen J. Turnbull]

Paul Moore writes:

 > With provisos. Figuring out contracts in sufficient detail to use
 > the code is *in many cases* simple. For harder cases, agreed. But
 > that's why this is simply a proof that contracts *can* be useful,
 > not that 100% of code would benefit from them.

Note that that is not what Marko wrote: he wrote that 100% of projects
on PyPI would benefit.  Like others, I'd like to see at least a
before/after on *one* whole project (that's not tiny, so it has
several meaningful APIs and several calls for at least a few of them),
to see *how much* of that project actually benefits, and how much of
that benefit derives from "more sophisticated than assert" DbC tech.

For now, I think the whole thread is technically speaking off-topic,
though.  Let's stipulate that DbC is a valuable technology that Python
programmers should have available.

(1) Why is it so valuable that it needs to be in the python.org
    distribution?  We already have asserts for the simplest cases.
    Won't PyPI do for the full-blown Meyer-style implementation?
    Development discussion for that implementation should take place
    on GitHub[1] or a similar channel, IMO.

(2) We don't have an implementation to include, or if you like there
    are many PoCs, and there's no good reason to suppose that there
    will be consensus on the candidate for inclusion in this decade.
    Again, development discussions for those implementations should
    take place on GitHub before coming here to discuss (a) which is
    best for the stdlib, (b) whether it's good enough, and (c) whether
    it's needed in the stdlib at all.  Is there a clear, leading
    candidate that could be proposed "soon", icontracts maybe?

(3) The syntaxes proposed so far require inelegant constructs, like
    lambdas or strs, so that decorator arguments can be evaluated
    lazily.  Lazy evaluation of arguments is something that newcomers
    often want after being burned by "def foo(l=[]):".  But there are
    at least two plausible ways to handle this.  One is like Lisp
    macros:  "defmacro mfoo(not, one, of, its, args, is, evaluated)".
    Another would be a marker for args to be returned unevalled:
    "def foo(eval_me, eval_me_not: unevalled, eval_me_too)".[2]

    Thus, unevalled arguments *may* be a plausible syntax change that
    would help support DbC as well as other possibly desirable use
    cases, but we have no proposal to discuss.  Do we?

I'm not yet suggesting that this thread *should* be terminated here
(and that's not to avoid charges of hypocrisy as I post to other
subthreads ;-).  But I think we should be continuously aware of the
three questions I posed above.


Footnotes: 
[1]  Personally, I'd prefer it be GitLab. :-)

[2]  Yes, I'm teasing the type annotations folks, I doubt this syntax
will fly.