On 21 April 2015 at 11:56, Rob Cliffe <rob.cli...@btinternet.com> wrote:
> On 21/04/2015 10:33, Cory Benfield wrote: > > On 21 April 2015 at 10:10, Chris Angelico <ros...@gmail.com> > <ros...@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.). > Documentation is not checked. It often loses sync with the actual code. Docs say one thing, code does another. Documenting types in docstrings forces you to repeat yourself. You have to write the parameter names twice, once in the function definition line, another in the docstring. And you need to understand the syntax of whatever docstring format will be used to check the code. I'm sure I'm not the only one that thinks that type hints actually *improve readability*. I will not argue whether it makes the code uglier or prettier, but I am certain that most of the time the type hints make the code easier to read because you don't have to spend so much mental effort trying to figure out "gee, I wonder if this parameter is supposed to be bool, string, or int?" The type (or types) that a parameter is expected to have becomes explicit, otherwise you have to read the entire function body to understand. > (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. > Even if it only helps in the simplest cases, it saves the reader of the code a lot of effort if you add up all those little cases together. My suggestion, wherever an annotated type is too complex, don't annotate it. If you do /only/ the simple cases, the end result is easier to read. > > 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. > Oh, $DEITY, I really hope this is not going to be another excuse lazy programmers will use to avoid porting to Python 3 :-( > Best wishes > Rob Cliffe > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com > > -- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
