[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Cem Karan]

On Jan 17, 2015, at 9:27 PM, Ben Finney <ben+python at benfinney.id.au> wrote:

> Cem Karan <cfkaran2 at gmail.com> writes:
> 
>> […] I feel like annotations have the capability to be MUCH more useful
>> than just as a place to hold type hints.
> 
> They have that capability. How long do you propose we wait for this
> capability to be realised?
> 
> Function annotations have been part of Python since version 3.0, and
> Guido (IIUC) is deciding that the wait is over: we already have the best
> use of function annotations we're going to get.

I understand what you're saying, and you're right that they are not used much.  I only learned about them after I started playing with Python 3.3.  But then I'm the bleeding edge for my group at work; everyone else is down in the python 2 world somewhere (some of them are WAY down there somewhere).  

Changing a language takes time.  Do you program in C?  Do you still use pthreads? Why? C11 specifies the thread.h header, you should switch to C11 threads right now!  Except... many compilers still don't fully support C11, so we're coding to an earlier standard.  There is a lot of code that already works as it is. Etc., etc. etc...

When a language changes, there is a LOT of catching up to do.  First, tools need to support the new facilities and then programmers need to become aware of new facilities, and they have to realize there is a legitimate use for those facilities.  Most people I know are unaware that annotations exist; that is an argument for making the change to supporting typing only, simply because there will be fewer people that are affected.  At the same time, if someone has a really good idea that could be layered into annotations WELL, they will be hampered by a proposal that locks them out.  If typing is done via a Typing class like I mentioned in my last email, then there is a very simple way of determining if we're looking at a type or at something else.  There may be other, better ways of layering it in that don't lock other uses out, and which are better suited for static analysis.

I'm just asking for a very simple, very clear method of distinguishing uses when parsing code.  Types can get complicated quickly, and ad-hoc rules to determine if we're looking at a type, or at something else, can get us in trouble.  Simply turning it on or off for a chunk of code also sucks; I LIKE types, so I'd like to put them into my code, but if I have a way of adding documentation to my code as well, then I'd like to do that in addition to the types.  There may be other uses of annotations that programmers haven't yet thought of, simply because they don't know that annotations exist.  Locking out those uses would suck.

Does all this make sense?

Thanks,
Cem Karan