PEP 3107 – Function Annotations in Python 3 | Hacker News Reader

PEP 3107 – Function Annotations in Python 3

legacy.python.org

39 pointsSpittie23 comments

Lacks compositional abilities as specified, which is unfortunate. If two libraries want to use this at the same time for two different purposes, there's no standard given for it.

I guess I have to admit that my feeling is that in our rich existing language ecosystem, features that seem designed to help turn Python into something it isn't just waste time and steps Python that much closer to Enterprise-class complexity. Maybe what Python really needs most right now is just a straight-up language freeze. It's done, it is what it is, what it is is pretty darned good for a lot of use cases, and that last bit can't be highlighted enough. It isn't going to be a static language wonder, it isn't going to have generalized C-class performance, it isn't going to become a great hugely-concurrent multithreading language, and you know what? That's OK. It's better to be a good Python than to be a bad not-quite-anything.

By a language freeze, you mean that Python should never change again?

Or at least, raise the bar on changes much, much higher. Total freeze is probably an unrealistic goal, but a at least a "conceptual" freeze, yes.

I've added a type checking decorator for function annotations to my assertions helper library, https://github.com/kislyuk/ensure:

    from ensure import ensure_annotations

    @ensure_annotations
    def f(x: int, y: float) -> float:
        return x+y

    f(1, 2.3)
    >>> 3.3
    f(1, 2)
    >>> ensure.EnsureError: Argument y to <function f at 0x109b7c710> does not match annotation type <class 'float'>

It's useful sometimes.

How does that work? Is it abusing dictionary syntax without braces?

The PEP describes it nicely :)

I'm not a huge fan of the "->" syntax myself, but I'm not sure what would work better.

OK, I'll bite: This is from [2010], so rather old.

What changed to make this relevant now?

I think it's because some people are finally considering making pure python3 projects.

No: this is from 2006; it was last modified in 2010, but the changes were negligible (a wording tweak), and earlier changes were even less important (updating hyperlinks).

> What changed to make this relevant now?

Python is increasingly losing ground to the new "it"-languages. To stay relevant, it needs cryptic syntax of dubious value so bloggers can write lengthy articles about useless applications for this new feature.

You can say the same for Algol or Cobol.

But then the stupidity of the statement would be immediately apparent.

What examples do you have (Go?), and do you have any charts that you drew insight from to say that? Of course, I have already been Googling the issue, but we aren't necessarily looking at the same sources.

So where are you getting your information that Python is losing to the "it" languages?

That's pretty cool. I like how it would seem to support literate programming at a lower level than just extensive comments (which always seem to go stale) or long variable names (which often hinder comprehension more than they help it).

A feature without a use case still unfortunately. There are some in the PEP, but given how little code is Py3-only, no one has written anything notable that I've seen that makes use of these.

i agree with your sentiment but not how you have literally worded it - there are plenty of serious use cases listed in the PEP, eg typechecking by itself is rather useful in other languages, but it is perhaps hard to imagine how useful this feature will be if no existing libraries support it, and there is no common standard defining what any of the annotations could mean.

on the other hand, this could be quite useful for large (proprietary?) python codebases where common standards can be defined and rolled out and enforced.

One use case: improved JITer performance.

It is nicely integrated with type checking in the pycharm IDE. This feature is one of the reasons I would personally like to write pure py3 code.

This would be great to have some subset of Cython[1] become valid Python code so it could be executed as normal Python code. The syntax is different, but function annotations could provide the necessary info.

[1] http://cython.org/

It's already available as a beta feature in Cython.

Link?

http://article.gmane.org/gmane.comp.python.cython.user/11014

There is a pure python mode http://docs.cython.org/src/tutorial/pure.html that works even in Python 2.

As mentioned, PyCharm supports this – I found it very useful when writing large amounts of code, saves time when trying to remember what type which variable should be (sometimes it's not evident from the input variable names).

And this looks a tad easier to find and understand than the standard docstring variable types description.

Reply on news.ycombinator.com