On Tue, Apr 21, 2015 at 12:50 AM Antoine Pitrou <solip...@pitrou.net> wrote:
> On Mon, 20 Apr 2015 20:43:38 -0400 > "R. David Murray" <rdmur...@bitdance.com> wrote: > > +1 to this from me too. I'm afraid that means I'm -1 on the PEP. > > > > I didn't write this in my earlier email because I wasn't sure about it, > > but my gut reaction after reading Harry's email was "if type annotations > > are used in the stdlib, I'll probably stop contributing". That doesn't > > mean that's *true*, but that's the first time I've ever had that > > thought, so it is probably worth sharing. > > I think it would be nice to know what the PEP means for daily stdlib > development. If patches have to carry typing information each time they > add/enhance an API that's an addition burden. If typing is done > separately by interested people then it sounds like it wouldn't have > much of an impact on everyone else's workflow. > Separately by interested people. That won't change until tools appear and mature that help maintain the types for us. (if ever) Nobody wants unreadable code. Nobody is proposing to make unreadable code happen or encourage its creation. One thing I feel is often overlooked in the discussion on this PEP: It is about creating a unified type expression syntax for everyone working on Python typing to centralize around. Regardless of if the PEPs version falls short for some purposes. It allows for sharing work. There are multiple ongoing projects that are trying to make use of type information with Python, this allows them to all speak the same language. (MyPy, MicroPython, Cython, the static analyzer we are trying to create at Google, several others not on the top of my head I'm sure, etc.) We will not be putting type annotations anywhere in the stdlib or expecting anyone else to maintain them there. That would never happen until tools that are convincing enough in their utility for developers to _want_ to use are available and accepted. That'll be a developer workflow thing we could address with a later PEP. IF it happens at all. I view most of this thread as FUD. The fear is understandable, I'm trying to tell people to stop panicing. This PEP does not mean that Python is suddenly going to become unreadable. Just that a set of people working on a common goal have a way to communicate with one another. If that work bears fruit, great, it'll be shared and provided as tools that people want to use. If not, it won't matter in the slightest and the typing module and this PEP will be relegated to history. This is a 100% non-invasive PEP. No new keywords! Motivation behind static analysis and type checkers comes directly from the success of the type annotations and checking done to Javascript in Google's javascript Closure compiler that has been available for years. Steven mentioned Facebook's Flow which does a similar thing. These are both opt-in and by and large we've found that developers love using them in any decent sized code base. That model is the goal for any of our Python typing related projects to get to. If developers don't _want_ to use it in the end, we have failed and they can happily continue not using it because it was never required. The reason this PEP exists is for tool developers to be able to do their thing and prove to everyone that it is (a) possible and (b) genuinely useful. IF that proves successful, we can consider if we need a saner syntax for anyone to want to use it. For now we've got this PEP which is a bit of a hack using the Python 3 annotations and a typing module but at the same time doesn't involve any language changes we might regret. I call that a win! -gps
_______________________________________________ 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
