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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
