Pretty impressive that the syntax:<p><pre><code> def greeting(name: str) -> str:
</code></pre>
Turns out to be <i>backwards</i> compatible in Python3 before 3.5 (though not Python2, yet another reason, if you actually needed one, to start new stuff in Python3)
Recently stumbled upon IntelliJ using the Go plugin package after a Rubyist friend of mine spoke very highly of RubyMine. I have to say I was incredibly impressed. I looked at it a couple years ago when I was mostly Python and it was ok, but it's really stepped up its game - both feature-wise and visually.<p>The IntelliJ IDE set is really far better than I understood. IMHO.
I can see this being very useful in teams. Hell, its even useful for a single developer as a form of future documentation. I generally write code today and think, when I read this in 6 months and have no memory, how can I help my future self? For new code bases I'll be adding this.
I wonder why, given they call it 'type hints', they didn't go for Haskell-like type comments:<p><pre><code> #greeting :: (str, int) -> str
def greeting(name, age):
</code></pre>
In fact, I wonder why more languages don't adopt this syntax, since it greatly simplifies functions with very large types.
There's quite some dissonance between the artificial "generics" vs normal types. Why the concrete str type for strings, but not for lists? I realize there are implementation level arguments for it, but the resulting compromise does not seem good.<p>And specifying the concrete str type goes diametrically against the "don't check against a concrete type, embrace duck typing" mantra that Python programmers are taught early.
something that's always had me a bit confused:<p>the type hinting in Python is just that -- <i>hinting,</i> right?<p>It's for IDEs like PyCharm to use to generate better docs and to be more intelligent about suggestions when writing code. But what it does NOT do is inform the interpreter/compiler about type information, correct?<p>I.e., Python3 code with perfectly implemented type hints would only make it easier on the developer, and not the interpreter/compiler, yeah?
"Type hinting" without checking is kind of lame. If you're going to have declarations such as<p><pre><code> def zero_all_vars(vars: Iterable[LoggedVar[int]]) -> None:
</code></pre>
people are going to get them wrong some of the time. Dumping the checking problem on some IDE, with a very vague specification of what an error is, is not progress. If functions have type specifications, you should not be able to call them with the wrong type, ever. This is the job of the compiler and the run time system, not the IDE.<p>Somebody should stop Python's little tin god before he creates another giant step backwards like the Python 2 to 3 mess.
I have fond memories of using Python 8-10 years ago, but looking at it today, I'm not sure I see compelling reasons not to just use C# instead.<p>I can have real static typing if I want it. I can also have dynamic typing if I want that. I can use lambda functions. I have LINQ. I can use ScriptCS or some of the new Roslyn stuff if I want to use it as a scripting language. Unix support is not as great, but they are coming along with that. There's no GIL.<p>Is there some killer feature for Python that I'm overlooking?
I like this. I use Ruby as a scripting language more often than Python and I would be happy to see similar additions to Ruby to improve code readability and IDE support (although RubyMine) does an awesome job of warning of possible code problems just using code inspection).<p>I sometimes wish that one programming language would work for all of my requirements but I keep needing: scripting languages for quickly getting stuff done; practical languages like Clojure and Java, and type strict languages like Haskell (that I would like to use more, but development takes longer).<p>Looking ahead a few years, the ideal for me would be a loose scripting language that had awesome static analysis tools. So, for example, I would get the safety of Haskell when hacking in Ruby.
It's cool that PyCharm added support for this -- the point of the typing module and the type hinting PEP is for IDEs to adopt it for linting purposes.<p>For those of you using vim, emacs, and the standard UNIX editing toolchain, the mypy linter provides command-line support. This blog post from April 2015 describes the first version of mypy that includes support for the official typing library.<p><a href="http://mypy-lang.blogspot.co.uk/2015/04/mypy-02-released.html" rel="nofollow">http://mypy-lang.blogspot.co.uk/2015/04/mypy-02-released.htm...</a>
Can this be fixed?<p><a href="http://stackoverflow.com/questions/25588642/pycharm-false-syntax-error-using-turtle" rel="nofollow">http://stackoverflow.com/questions/25588642/pycharm-false-sy...</a>
Has someone tried GNOME Builder? I found it quite good for C, but the Python mode of PyCharm is still superior regarding search and introspection, yet it is not Free Software…