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.
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.
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.
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).
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.
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?
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'>
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).
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.
23 comments
[ 5562 ms ] story [ 1286 ms ] threadon the other hand, this could be quite useful for large (proprietary?) python codebases where common standards can be defined and rolled out and enforced.
[1] http://cython.org/
And this looks a tad easier to find and understand than the standard docstring variable types description.
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.
But then the stupidity of the statement would be immediately apparent.
So where are you getting your information that Python is losing to the "it" languages?
I'm not a huge fan of the "->" syntax myself, but I'm not sure what would work better.
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.