On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich <jackd...@gmail.com> wrote:
> Twelve years ago a wise man said to me "I suggest that you also propose a > new name for the resulting language" > The barrage of FUD makes me feel like the woman who asked her doctor for a second opinion and was told "you're ugly too." > I talked with many of you at PyCon about the costs of PEP 484. There are > plenty of people who have done a fine job promoting the benefits. > So excuse me if I also defend the PEP against your attack. > * It is not optional. Please stop saying that. The people promoting it > would prefer that everyone use it. If it is approved it will be optional in > the way that PEP8 is optional. If I'm reading your annotated code it is > certainly /not/ optional that I understand the annotations. > The PEP 8 analogy is actually great -- that PEP's style advice *is* optional and plenty of people ignore it happily. The benefits come out when you're sharing code but violations are no big deal. And as to requiring what the annotations mean: the CPython interpreter itself doesn't even use them when executing your code, so you can certainly pretend that the annotations aren't there and read the body of the function or the docstring instead. > * Uploading stubs for other people's code is a terrible idea. Who do I > contact when I update the interface to my library? The random Joe who > "helped" by uploading annotations three months ago and then quit the > internet? I don't even want to think about people maliciously adding stubs > to PyPI. > We're certainly not planning to let arbitrary people upload stubs for arbitrary code to PyPI that will automatically be used by the type checkers. (We can't stop people from publishing their stubs, just as you can't stop people from writing blog posts or stackoverflow answers with examples for your library.) The actual plan is to have a common repository of stubs (a prototype exists at https://github.com/JukkaL/typeshed) but we also plan some kind of submission review. I've proposed that when submitting stubs for a package you don't own, the typeshed owners ask the package owner what their position is, and we expect the answers to fall on the following spectrum: - I don't want stubs uploaded for my package - I'll write the stubs myself - I want to review all stubs that are uploaded for my package before they are accepted - Please go ahead and add stubs for my package and let me know when they're ready - Go ahead, I trust you This seems a reasonable due diligence policy that avoids the scenarios you're worried about. (Of course if you refuse stubs a black market for stubs might spring into existence. That sounds kind of exciting... :-) > * The cognitive load is very high. The average function signature will > double in length. This is not a small cost and telling me it is "optional" > to pretend that every other word on the line doesn't exist is a farce. > Have you never found yourself trying to read someone else's code and being stopped in your tracks because you couldn't find out what kind of argument was expected somewhere? I'm personally quite tired of seeing that an argument is a "file" and not knowing whether it's meant to be an IO stream or a filename (and was that bytes or unicode? :-). Or seeing something documented as "creation time" without knowing whether that's a datetime or a a POSIX timestamp (or maybe milliseconds or a string encoding a date). Etc., etc. And yes, you can put the info in docstrings or comments (though it won't be less verbose, and it will be more likely wrong). One way to see type hints is as a way to save on docstrings and comments by using a standard notation that ties type info to the argument without the need to repeat the argument name. Yes, you need to use your brain. But don't tell my that all the Python code you read or write is self-explanatory, because it isn't. > * Every company's style guide is about to get much longer. That in itself > is an indicator that this is a MAJOR language change and not just some > "optional" add-on. > Actually, standardization *reduces* the length of a company style guide, like PEP 8 did before. Would you rather have instructions for the specific linter your company uses, instead of the single phrase "use type hints (PEP 484)"? > * People will screw it up. The same people who can't be trusted to program > without type annotations are also going to be *writing* those type > annotations. > I don't follow this argument. So what? People will screw up anything you give them. introspection, metaclasses, import hooks, reduce(), you name it. > * Teaching python is about to get much less attractive. It will not be > optional for teachers to say "just pretend all this stuff over here doesn't > exist" > This argument is particularly weak. Teachers are actually *very* effective teaching only the parts of Python they need -- some start with just functions and variables. Others with just classes and methods. Few ever even teach operator overloading. > * "No new syntax" is a lie. Or rather a red herring. There are lots of new > things it will be required to know and just because the compiler doesn't > have to change doesn't mean the language isn't undergoing a major change. > The language undergoes major changes all the time. There was a time before context managers. You've survived print() becoming a function. We're getting a matrix multiply operator. The sky isn't falling. > If this wasn't in a PEP and it wasn't going to ship in the stdlib very few > people would use it. If you told everyone they had to install a different > python implementation they wouldn't. This is much worse than that - it is > Python4 hidden away inside a PEP. > But the nice thing is that this time you really *can* mix Python 3 and Python 4 together in one app. :-P > There are many fine languages that have sophisticated type systems. And > many bondage & discipline languages that make you type things three times > to make really really sure you meant to type that. If you find those other > languages appealing I invite you to go use them instead. > > -Jack > https://mail.python.org/pipermail/python-dev/2003-February/033291.html > So finally it's payback time? Well played sir. :-) -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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
