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

Guido van Rossum guido at python.org
Sun Jan 18 20:34:03 CET 2015

On Sun, Jan 18, 2015 at 5:37 AM, Cem Karan <cfkaran2 at gmail.com> wrote:

> 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?

I hear you, and I'm not buying it. I've thought about this a lot (more than
you, I'm sure) and I'm putting a line in the sand: annotations are for
types, and all other uses will eventually have to find some other way (most
likely decorators). (The "type: OFF" comments are a transitional measure to
avoid breaking other uses without warning in 3.5.)

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150118/2a94c63c/attachment-0001.html>

More information about the Python-ideas mailing list