<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 21/04/2015 10:33, Cory Benfield wrote:<br>
<blockquote
cite="mid:CAH_hAJEGXVNH=iK01=gr_B8H2FdH+KOxDJBXoOSLoMEtUmHghw@mail.gmail.com"
type="cite">
<pre wrap="">On 21 April 2015 at 10:10, Chris Angelico <a class="moz-txt-link-rfc2396E" href="mailto:rosuav@gmail.com"><rosuav@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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].
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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).<br>
<br>
The refreshing thing about Python is that it is a fantastic, <b>concise</b>,
dynamically typed language, at the opposite end of the spectrum from
C++ (ugh!).<br>
We have got used to the consequences (good and bad) of this:<br>
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.<br>
Not to mention objects of some class that will be written in
5 years time.<br>
(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?<br>
Is Fraction? What about complex numbers, which can't be
sorted? What if the function were written before the Decimal
class?)<br>
Errors are often not caught until run time that would be caught
at compile time in other languages (though static code checkers
help).<br>
(Not much of a disadvantage because of Python's superb error
diagnostics.)<br>
Python code typically says what it is doing, with the minimum of
syntactic guff. (Well, apart from colons after if/while/try etc. <span
class="moz-smiley-s1"><span> :-) </span></span>)<br>
Which makes it easy to read.<br>
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.)<br>
<br>
Chris A makes the valid point (if I understand correctly) that<br>
Authors of libraries should make it as easy as possible to <br>
(i) know what object types can be passed to functions<br>
(ii) diagnose when the wrong type of object is passed<br>
Authors of apps are not under such obligation, they can
basically do what they want.<br>
<br>
Well, <br>
(i) can be done with good documentation (docstrings etc.).<br>
(ii) can be done with appropriate runtime checks and good error
messages.<br>
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).<br>
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.<br>
But what the hell, writing a production-quality library is not an
exercise for newbies.<br>
<br>
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, <b>not
simple at all</b>, viz. "Is this passed object suitable?".
Attempting - and failing, except in the simplest cases.<br>
<br>
Apologies, Guido, but:<br>
There was once a Chinese student who was a marvellous painter. He
painted a perfect life-like picture of a snake.<br>
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.<br>
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.)<br>
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.<br>
<br>
Best wishes<br>
Rob Cliffe<br>
</body>
</html>