[Python-ideas] Pre-conditions and post-conditions

[Steven D'Aprano]

On Tue, Sep 04, 2018 at 12:08:31AM +0100, Ivan Levkivskyi wrote:
> On Mon, 3 Sep 2018 at 23:51, Greg Ewing <greg.ewing at 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