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

[Harry Percival]

Hey, I just wanted to say to everyone, thanks for being so patient and
willing to engage with this discussion, despite my not having done my
research and read the (substantial) prior discussion on the topic.  Here it
is (or at least, some of it!) for any other newcomers:


https://mail.python.org/pipermail/python-list/2015-January/697202.html
https://mail.python.org/pipermail/python-list/2015-January/697315.html
https://github.com/ambv/typehinting/issues/55

I'm not sure any of it will radically change anyone's mind.  Everyone (I
think) agrees that type hints carry some cost in terms of legibility and
simplicity of the language.  Everyone agrees they have some benefits.  The
disagreement remains over whether it will be worth it, and whether stub
files vs inline vs something-else would be the best place to hide them.

Is "let's wait and see" an acceptable position?  Probably the only real way
to resolve the disagreement is to start seeing the type hints in use, and
form opinions based on real-world practice.  Some people will like them
inline.  Lots of people will use stub files, since they're the only way to
maintain 2+3 compatibility, so it's my home that the community will
standardise around that.  Still other people will want to have another
crack at using docstrings, but the standardisation on notation of types
will still help them.  And still other others will want no part in them,
and will argue against them in their communities.   Hopefully a best
practice will evolve.  And hopefully it'll be the stub file one, and then
we really can deprecate function annotations in 3.6 ;-)


On 21 April 2015 at 11:56, Rob Cliffe <rob.cliffe at btinternet.com> wrote:

>  On 21/04/2015 10:33, Cory Benfield wrote:
>
> On 21 April 2015 at 10:10, Chris Angelico <rosuav at gmail.com> <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
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net
>
>


-- 
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype:         harry.percival
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150421/65621cec/attachment.html>