[Python-ideas] Optional static typing -- the crossroads

[Nicholas Cole]

On Sun, Aug 17, 2014 at 3:08 AM, Steven D'Aprano <steve at pearwood.info> wrote:

> I don't think this is a shining example of the value of static typing,
> at least not by default. As I see it, you would get something like this:
>
>     def __init__(self,
>             description:str, sec_code:str,
>             vendor_name:str, vendor_inv_num:str,
>             vendor_rtng:str, vendor_acct:str,
>             transaction_code:str, vendor_acct_type:str,
>             amount:int, payment_date:Any)->None:
>
> which may not give you much additional value. In this case, I think that
> the static checks will add nothing except (perhaps) allow you to forgo
> writing a few isinstance checks. You still have to check that the
> strings are the right length, and so on.
>
> But if you're willing to invest some time creating individual str
> subclasses, you can push the length checks into the subclass
> constructor, and write something like this:
>
>     def __init__(self,
>             description:Str10, sec_code:SecurityCode,
>             vendor_name:Str22, vendor_inv_num:Str15,
>             vendor_rtng:Str9, vendor_acct:Str17,
>             transaction_code:ACH_ETC, vendor_acct_type:VendorAcctType,
>             amount:Pennies, payment_date:DateABC)->None:

I know that the BDFL has spoken on this issue and said that he finds
all of this readable and "pythonic", but these examples perfectly
capture what I am going to dislike about this syntax as it becomes
popular.

I suppose it will be better when I am reading it in an editor that has
syntax highlighting but as it stands I had to stare at that block of
code for a long time to see how many and what type of arguments it
called.  At first I thought you had one per line, then I thought you
had variable numbers per line.  On about the fourth or fifth reading,
I saw you had two per line.  The problem with the syntax (I think) is
that it relies on readers spotting characters like ":" and "[",
characters which change how the eye should parse the line (assuming
this is going to be optional).  I find that those characters get lost
very easily in long function definitions, leaving the reading having
to read and re-read the block to answer questions like, 1. how many
arguments are there? 2. Are any of them keyword arguments? Are they
all the same type? 3. What are their names? In the example above, my
eye keeps wanting to tell me that one of them is called SecurityCode,
for example, even though I know that is the name of a class. This all
seems unpythonic to me.  Most of python's syntax is expressed in words
rather than compact symbols.

My fear with all of this is that it turns python into a language that
is harder for humans to read.  I much prefer the PyCharm docstring
approach, because the eye can scan the function signature quickly and
then the brain can say, "Ah - 10 arguments, oh, and I see that they
have to be particular types and the return code is specified."  To put
it another way, current python function signatures are immediately
intuitive even to someone who is unfamiliar with the language.  There
is nothing intuitive about this.  It is more like looking at
ObjectiveC or similar.

At root, I don't totally understand what is "Pythonic" about function
signatures. On the other hand, more expert people than me seem to like
the above, and so I am sure that I am missing something.  Perhaps it
is simply the DRY principle.  On the other hand, I am sure that
readability issues are not simply a matter of personal taste.  I've
just re-read Tog on Inerterface, and perhaps that is colouring my
thought!

Anyone who is at all dyslexic is, I think, going to struggle!

PEP8 should probably specify one argument per line if this kind of
syntax is going to be at all re-readable.

However, I do accept that the BDFL has spoken, and I'll "get with the
program"!  I'm sure I'll get used to it.

N.