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

Yann Kaiser kaiser.yann at gmail.com
Tue Jan 20 00:11:23 CET 2015

Before I forget, your typical forward-reference problem will most likely
look like this:

class X(...):
    def method(self, other:: X):

On Mon Jan 19 2015 at 11:15:05 PM Guido van Rossum <guido at python.org> wrote:

> On Mon, Jan 19, 2015 at 12:30 PM, Devin Jeanpierre <jeanpierreda at gmail.com
> > wrote:
>> On Sun, Jan 18, 2015 at 4:01 PM, Greg <greg.ewing at canterbury.ac.nz>
>> wrote:
>> > Do you mean *static* types, or types in general?
>> >
>> > If they're only for static type checking, this seems a waste of a
>> > facility that evaluates things at run time. Moreover, evaluating
>> > them at run time is actually counterproductive, since it makes
>> > dealing with things like forward references unnecessarily awkward.
>> > It also introduces useless runtime overhead. And they only address
>> > part of the problem, since they only apply to functions and not
>> > other things we might want to specify the type of.
>> Strong +1. The current proposal is a historical accident, it would not
>> be designed this way if it was designed from scratch. That's not a
>> nice thing to include in the core language. (Although it does happen
>> often, since "practicality beats purity").
> It's stronger than that. I'd say that all of Python is a historical
> accident.
>> I like the :: idea.
> Blechh. It smells of C++ and syntax hacks. PEP 3107 is over 8 years old
> (also a historical accident :-). Let's stick with the devil we know.

You know, I feel pretty good when I get to write python helper scripts in
Python 3 because I get to write

    def my_script(address, *, port:'p'=80):

rather than

    def my_script(address, port=80):

With just one parameter to annotate, we go from 19 characters plus imports
in Python 2.7, to just 4. In 4 characters, in just as much clarity as with
19, I made "-p 8080" synonymous with "--port 8080". Didn't have to think it
through, didn't have to go back and add imports, just had to wish "it would
be nice if I could use -p instead".

That's what I had in mind when writing this argument parser, when I added
annotation support to it, when I made annotations the primary way of
specifying anything with it. Annotations have been great, and this little
project wouldn't have existed in another programming language.

Reserving annotations for typing info, as you suggested is your long-term
goal, takes that away and takes eager users of my library on Python 3
halfway back to Python 2.

Not cool.

I understand, from this thread and previous threads about this PEP, that
you intended from the get-go parameter annotations to be used for type
hinting and co. This appeared in the annotations PEP as a mere suggestion
in a bullet point list, and more importantly did not appear in the docs.

If the chain of historical accidents is to continue, maybe it shall include
Python opting to spawn a separate kind of annotation better-suited for
static analysis alongside the dynamic ones that can be used in all kinds of
stuff that look ugly in other languages.

If the problem against :: really is "There's no time before 3.5", that's
really just "Postpone it until 3.6" waiting to be said. That'll be more
time to see if whatever is drafted up is useful to static analysis tools
and statically-analysed code bases. It has already waited 24 years after
all. As for C++'s infamous "> >" vs ">>", "::" isn't comparable because ":
:" does not exist and isn't about to. (Right?)

The :: idea otherwise brings advantages to all as outlined before, so I'm a
bit frustrated to see it dismissed on mere feeling.

> --Guido van Rossum (python.org/~guido)
>  _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150119/1c5632b5/attachment-0001.html>

More information about the Python-ideas mailing list