[Python-ideas] Proposal: Use mypy syntax for function annotations

Thu Aug 14 18:01:37 CEST 2014

I am strongly opposed to this entire proposal. As Juancarlo points out,
Python programs are small, but very understandable. I think this syntax
detracts from that. I'll suggest an alternative further down in my reply.

One benefit of Python that makes it so attractive for new programmers and
even old programmers alike is that you can usually pick out any piece of
Python code and begin to understand it immediately. Even if you come from a
different programming language, Python is written in
english explicitly using words like "and" and "or". Those constructs, as
opposed to "&&" or "||" make the language less scary for new developers and
in general easier to read as well. It's also easier to type regular english
words (no need to use the shift key). Using the annotation syntax this
heavily will detract very much from the readability of Python and from the
overall usability as well. Programs are read more times than they are
written.

Several years ago, before I had any programming experience in any language
at all, I needed to edit some Python code to make something I was doing
work. Without any experience at all, I was able to look through the (small)
program I was editing and figure out exactly what I needed to adjust.
Without Python being such a clean, almost English language, that would have
been impossible.

Though the annotation syntax is already present in Python 3, I would argue
that using this for type annotations will get very messy very quickly. If
I'm understanding the syntax correctly, writing any function using a large
library with many nested subpackages could result in code like this:

    import twisted.protocols.mice.mouseman

    def
process_mouseman(inputMouseMan: twisted.protocols.mice.mouseman.MouseMan)
-> twisted.protocols.mice.mouseman.MouseMan:
        pass

That function definition is 122 characters long. Far more than what PEP8
recommends. Though this example was crafted to illustrate my point (I don't
think most people would really write code like this), it is easy to see
that this kind of code is possible and may sometimes be written by some
less experienced programmers. It demonstrates how messy things can get even
with just one parameter.

It is also easy to see that it is very difficult to parse out what is going
on in that function. Adding type annotations inline makes it very difficult
to quickly get an idea of what arguments a function takes and in what
order. It detracts from the overall readability of a program and can also
lead to very poorly formatted programs that break the guidelines in PEP8.
Though I have only demonstrated this for function declarations, the example
could also be extended to inline statement comments as well. Things get too
messy too quickly.

My Alternative Proposal:
As an alternative, I would like to propose a syntax that Pycharm already
supports:
http://www.jetbrains.com/pycharm/webhelp/using-docstrings-to-specify-types.html

Since this type information isn't going to be used at runtime in the
regular Python interpreter anyway, why not have it in the function
docstring instead? This provides both readability and type checking.
Standardizing that syntax or at least adding it as an optional way to check
your program would in my opinion be a much better addition to the language.
This approach needs no new syntax, keeps readability and allows the
programmer to add additional documentation without going over the 80
character limit.

Additionally, this approach can be used by documentation generators as well
and removes any duplication from the function declaration and the docstring.

Here's a taste of what that looks like:
    class SimpleEquation(object):

        def demo(self, a, b, c):
            """
            This function returns the product of a, b and c
            @type self: SimpleEquation
            :param a: int - The first number
            :param b: int
            :param c: int - The third number should not be zero and should
also
                only be -1 if you enjoy carrots (this comment spans 2 lines)
            :return: int
            """
            return a * b * c

Overall, I think overloading function declarations and inline comments is a
bad idea. It promotes writing code with poor readability and in general
adds a lot of extra bits to the language that (from the sounds of your
proposal) aren't even going to be used by the main interpreter.

On the original proposal:
These changes really do seem to be overestimating the staticness of Python
programs as well. What about functions that don't care about the type? What
about functions that only want you to pass in an object that implements
__iter__? Python should not become a language where developers are required
to add hundreds of odd cast() calls every time they choose to pass a
different, but still compatible type, to a function. This syntax makes too
many assumptions about what developers know about their code. What if I
develop a similar, but different class that is compatible with an existing
function? If that function doesn't specify that my class can be used, my
perfectly valid code will be rejected.

-1 to adding mypy annotations to Python 3.

Sunjay

On Thu, Aug 14, 2014 at 10:59 AM, Juancarlo Añez <apalala at gmail.com> wrote:

>
> On Wed, Aug 13, 2014 at 3:14 PM, Guido van Rossum <guido at python.org>
> wrote:
>
>> I am proposing that we adopt whatever mypy uses here, keeping discussion
>> of the details (mostly) out of the PEP. The goal is to make it possible to
>> add type checking annotations to 3rd party modules (and even to the stdlib)
>> while allowing unaltered execution of the program by the (unmodified)
>> Python 3.5 interpreter.
>
>
> To the bottom of things...
>
> About the second time I wrote about Python ("Why not Python", 2007) I
> dismissed it as serious software development environment because the lack
> of static type checking hindered the creation of proper software
> development environments.
>
> http://blog.neogeny.org/why-not-python.html
>
> So, Why do I now have doubts about adding support for static type checking?
>
> I've been programming in almost-only Python for several years now, and
> this discussion had me think hard about "Why?".
>
> The answer is simple: I never was as productive as I've been since I've
> centered on Python.
>
> But, again Why?
>
> Despite what my '07 article says, the IDE I use is pythonized-VIM and the
> command line. Where does the productivity come from?
>
>    1. Readability with the right amount of succinctness. Python programs
>    are very small, but understandable.
>    2. The breadth and design consistency of the standard library. Some
>    70%? of what I need is there, and the design consistency makes it easy
>    (intiutive) to use.
>    3. PyPi covers another 28%.
>    4. The Zen of Python (import this) permeates all of the above,
>    including most third-party packages. The ecosystem is consistent too. It's
>    a culture.
>
> What do I fear? I think it is that Python be transformed into a
> programming language different from the one that now makes me so productive.
>
> I studied Ruby, and I don't like it. I've been studying Go, and I don't
> like it. One must like the concepts and the power, sure, but the syntax
> required for some day-to-day stuff stinks like trouble;  simple stuff is so
> complicated to express and so easy to get wrong...
>
> I hate "List[str]" and "Dict[str:int]". Where did those come from?
> Shouldn't they (as others have proposed) be "[str]" and "{str:int}"? What
> about tuples?
> Why not write a similar, but different programming language that targets
> the Cython runtime and includes all the desired features?
>
> All said, this is my proposal.
>
> The PSF could support (even fund) MyPy and similar projects, promoting
> their maturity and their convergence. The changes in 3.5 would be limited
> but enough to enable those efforts, and those of the several IDE
> tool-smiths (changes in annotations, and maybe in ABCs). Basically, treat
> MyPy as PyPy or NumPy (which got '::'). It's in Python's history to enable
> third-party developments and then adopt what's mature or become the
> de-facto standard.
> Then, on a separate line of work, it would be good to think about how to
> enable different programming languages to target the CPython environment
> (because of #2, #3, and #4 above), maybe by improving AST creation and
> AST-to-bytecode? There could be other languages targeting the CPython
> runtime, which is the relationship that Scala, Jython, IronPython, and
> others have to their own runtimes.
>
> -1 for standardizing static type checking in 3.5
>
> Cheers,
>
> --
> Juancarlo *Añez*
>
> _______________________________________________
> 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/
>

-- 
Sunjay Varma
Python Programmer & Web Developer
www.sunjay.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140814/334b83f1/attachment-0001.html>