[Python-Dev] Type hints -- a mediocre programmer's reaction

[Rob Cliffe]

On 21/04/2015 10:33, Cory Benfield wrote:
> On 21 April 2015 at 10:10, Chris Angelico <rosuav at gmail.com> wrote:
>> At this point, you may want to just stop caring about the exact type.
>> Part of the point of gradual typing is that you can short-cut a lot of
>> this. And quite frankly, this isn't really helping anything. Just skip
>> it and say that it's Union[Mapping, Iterable, None].
> I think this is my problem with the proposal. This change doesn't
> catch any of the bugs anyone was going to hit (no-one is passing a
> callable to this parameter), and it doesn't catch any of the bugs
> someone might actually hit (getting the tuple elements in the wrong
> order, for example). At this point the type signature is worse than
> useless.
Exactly.  At this point putting the type signatures in seems to be a 
pointless exercise in masochism (for the author) and sadism (for the 
reader).

The refreshing thing about Python is that it is a fantastic, *concise*, 
dynamically typed language, at the opposite end of the spectrum from C++ 
(ugh!).
We have got used to the consequences (good and bad) of this:
     Duck typing, e.g. a function to sort numbers (sorry Tim Peters bad 
example) turns out to support any kind of object (e.g. strings) that 
supports comparison.
         Not to mention objects of some class that will be written in 5 
years time.
         (Adding a type hint that restricted the argument to say a 
sequence of numbers turns out to be a mistake.  And what is a number?
          Is Fraction?  What about complex numbers, which can't be 
sorted?  What if the function were written before the Decimal class?)
     Errors are often not caught until run time that would be caught at 
compile time in other languages (though static code checkers help).
         (Not much of a disadvantage because of Python's superb error 
diagnostics.)
Python code typically says what it is doing, with the minimum of 
syntactic guff.  (Well, apart from colons after if/while/try etc. :-) )
     Which makes it easy to read.
Now it seems as if this proposal wants to start turning Python in the 
C++ direction, encouraging adding ugly boilerplate code.  (This may only 
be tangentially relevant, but I want to scream when I see some 
combination of public/private/protected/static/extern etc., most of 
which I don't understand.)

Chris A makes the valid point (if I understand correctly) that
     Authors of libraries should make it as easy as possible to
           (i) know what object types can be passed to functions
           (ii) diagnose when the wrong type of object is passed
     Authors of apps are not under such obligation, they can basically 
do what they want.

Well,
     (i) can be done with good documentation (docstrings etc.).
     (ii) can be done with appropriate runtime checks and good error 
messages.
E.g. (Cory's example) I'm sure it is possible to test somehow if an 
object is file-like (if only by trying to access it like a file).
Is thorough argument checking and provision of good diagnostics going to 
be easy for the library author?  No.  Is it going to be a lot of work to 
do thoroughly?  Almost certainly yes.
But what the hell, writing a production-quality library is not an 
exercise for newbies.

It seems to me that type hints are attempting to be a silver bullet and 
to capture in a simple formula what is often, in practice, *not simple 
at all*, viz. "Is this passed object suitable?". Attempting - and 
failing, except in the simplest cases.

Apologies, Guido, but:
There was once a Chinese student who was a marvellous painter.  He 
painted a perfect life-like picture of a snake.
But he was unable to stop and leave it alone.  In his zeal he went on to 
paint feet on the snake.  Which of course completely spoiled the 
picture, as snakes don't have feet.
Hence "to paint feet on the snake": to be unable to resist tinkering 
with something that is already good.  (I suppose "If it ain't broke, 
don't fix it" is an approximate Western equivalent.)
You see where I'm going with this - adding type hints to Python feels a 
bit like painting feet on the snake.  Or at least turning it into a 
different language.

Best wishes
Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150421/0e884f05/attachment.html>