On Tue, Sep 04, 2018 at 12:08:31AM +0100, Ivan Levkivskyi wrote: > On Mon, 3 Sep 2018 at 23:51, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > > Jonathan Fine wrote: > > > I've just read and article which makes a good case for providing > > > pre-conditions and post-conditions. > > > > > > http://pgbovine.net/python-unreadable.htm > > > > There's nothing in there that talks about PBC-style executable > > preconditions and postconditions, it's all about documenting > > the large-scale intent and purpose of code. He doesn't put > > forward any argument why executable code should be a better > > way to do that than writing comments. > > > > FWIW this article looks more like a typical motivational intro to static > types in Python :-)
Did we read the same article? This is no more about static typing than it is about contracts. It is about the need for documentation. The only connection here between either static typing or contracts is that both can be a form of very limited documentation: type declarations tell you the types of parameters and variables (but not what range of values they can take or what they represent) and contracts tell you the types and values (but not what they represent). The author explicitly states that statically typed languages have the same problem communicating the meaning of the program. Neither clean syntax (like Python) nor static types help the reader comprehend *what* the program is doing "in the large". He says: What's contained within allCovData and covMap (which I presume are both dicts)? What are the types of the keys? What are the types of the values? More importantly, what is the meaning of the keys, values, and their mapping? What do these objects represent in the grand scheme of the entire program, and how can I best leverage them to do what I want to do? Unfortunately, nothing short of having the programmer write high-level comments and/or personally explain the code to me can possibly provide me with such knowledge. It's not Python's fault, though; I would've faced the same comprehension barriers with analogous code written in Java or C++. Nothing is wrong with Python in this regard, but unfortunately its clear syntax cannot provide any advantages for me when trying to understand code 'in-the-large'. and later goes on to say: (To be fair, static types aren't a panacea either: If I showed you the same Java code filled with type definitions, then it would be easier to understand what this function is doing in terms of its concrete types, but without comments, you still won't be able to understand what this function is doing in terms of its actual underlying purpose, which inevitably involves programmer-intended 'abstract types'.) -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/