On Mon, 24 Sep 2018 at 19:47, Marko Ristin-Kaufmann <marko.ris...@gmail.com> wrote: > > Hi, > > Thank you for your replies, Hugh and David! Please let me address the points > in serial. > > Obvious benefits > You both seem to misconceive the contracts. The goal of the > design-by-contract is not reduced to testing the correctness of the code, as > I reiterated already a couple of times in the previous thread. The contracts > document formally what the caller and the callee expect and need to satisfy > when using a method, a function or a class. This is meant for a module that > is used by multiple people which are not necessarily familiar with the code. > They are not a niche. There are 150K projects on pypi.org. Each one of them > would benefit if annotated with the contracts.
You'll lose folks attention very quickly when you try to tell folk what they do and don't understand. Claiming that DbC annotations will improve the documentation of every single library on PyPI is an extraordinary claim, and such claims require extraordinary proof. I can think of many libraries where necessary pre and post conditions (such as 'self is still locked') are going to be noisy, and at risk of reducing comprehension if the DbC checks are used to enhance/extended documentation. Some of the examples you've been giving would be better expressed with a more capable type system in my view (e.g. Rust's), but I have no good idea about adding that into Python :/. Anyhow, the thing I value most about python is its pithyness: its extremely compact, allowing great developer efficiency, but the cost of testing is indeed excessive if the tests are not structured well. That said, its possible to run test suites with 10's of thousands of tests in only a few seconds, so there's plenty of headroom for most projects. -Rob _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
