[Python-ideas] Optional static typing -- late to the party

Tennessee Leeuwenburg tleeuwenburg at gmail.com
Wed Aug 20 14:08:48 CEST 2014


Hi all,

I apologise in advance for being across only that proportion of the
previous correspondence that I could read in about half an hour. Too much
has been said to fully integrate it all.

I have some responses to what was written, and one of those I feel has been
largely missed. Please accept this as "just some stuff I think" and not any
kind of strident criticism or positioning.

The primary goal should be a syntax which enhances human readability. While
I agree that having good static code analysis tools is very useful for the
write --> test --> fix cycle, actually the more bugs you can catch during
the human read/understand/write cycle, the better. The earlier you can
communicate useful information about variable types, the better, and the
earliest stage of that is code comprehension at the human level.

I mostly agree with those who are preferring docstring embedding over
signature decoration, particularly for complex cases, due to the desire to
separate the complexity into structured sections. The signature is like the
heading, and the annotation is like additional detail.

I was led to a conclusion: what is wrong with allowing both? Indeed,
clearly both are actually already supported by various tools. So perhaps
there is actually a higher-level common concept -- what are the actual
assertion which are going to be supported? Can I declare a variable only to
be a list, or can it be a list-of-ints?

Further, is it possible to standardise between some of the
syntax/terminology, and some of the assertion types, such that they are
consistent between function annotation syntaxes and docstring embedding
syntaxes? Could I use function annotation for simple cases, but seamlessly
move to a docstring-embedded approach for a more complex example?

e.g.

def frobnicate(x: int, y: int) -> float
    '''
    Applies some kind of standard function
    '''
    return x**2 / y

is great.

But

def handle_complex_case(name, context, objective, datacube):
   '''
   @param name: str, contains a "Firstname Lastname" string
   @param context: dict, contains a data record
   @param objective: int, contains a coded directive
   @param datacube: numpy.array, contains a field of continuous spatial data

   @return: instructionset: list(callable), a list of callable instructions
   '''

allows me to describe what's going on in that function in a way which
supports both typing and static analysis. Apologies for inventing the
docstring syntax rather than correctly using an existing syntax. However,
my point is that in the first example, an annotation approach is *more*
readable. In the second example, you really want to spend more time
describing and annotating the function.

If there could be some agreement about the details and consistency, I see
no reason that a dual style could not be preferable, and no more complex to
understand and use.

Regards,
-Tennessee Leeuwenburg

-- 
--------------------------------------------------
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140820/6c9e8f32/attachment.html>


More information about the Python-ideas mailing list