Static vs dynamic languages is topical

Skip to “PyCharm’s sucky refactorings” if you don’t have much time.

Why Java? Tales from a Python Convert Discussed three times on Reddit:

Then there was The End of Dynamic Languages by Elben Shira, a follow up - Have Static Languages Won? by Maxime Chevalier-Boisvert, and one more - THE SKY IS NOT FALLING by Dmitri Sotnikov.

All good reads. Elben Shira focused on DSLs and then Clojure as problematic, and I think that really detracted from his strong point about dynamic languages:

“Every library function you call, unless you have it memorized, requires hunting down the source or test files for examples on how to use it”

That echos with my frustration as I am improving my Python - slower by far than my speed at developing with Java (even if ultimately the libraries are easier to use).

Example code by the shovelful, people!

I rely on the intellisense of the JetBrains products to get me there generally, but sometimes I’m off to google or stackoverflow for how-to. Some language/librrary/framework authors don’t like to include examples in their API documentation. Sure railroad diagrams are pretty, but if you don’t have a few examples of use inlined with your API doc you just disenfranchised significant percentage of programmers who learn exclusively by looking at good examples of use. Yes, people learn things differently. Some like tutorials, yet some no love for them. Some like API docs, yet some feel naked if that’s all they have. Some people need examples (and permutations thereof) to get there.

PyCharm’s sucky refactorings

Note: Jetbrains’ IDEs have been the worlds best for 16 years straight.

Here’s the high bar for refactoring - Danio Sato moving code like it were wet paint perfectly safely (ffwd 2.5 minutes to skip the explanation of the experiment). This is only 12 mins of your time, and you should be changed if you’ve never seen Intelli IDEA in action before, in the hands of an expert at least. Danilo’s blog entry on the same.

Except you can’t do more than 20% of that in PyCharm (sister product to Intellij IDEA - compiled from the same codebase).

Extract Parameter

I’ve taken Shane Engelman’s Python OO example from Github for a discussion. I’m going to try to “extract parameter” (Danilo showed that ten times or so in 12 minutes):

PyCharm knows that Dog is a subclass of Animal (look in the left margin), and that the sleep() method is overridden. Yet when I do the refactoring operation, it is only offering an optional parameter refactoring. It is not asking me if I want to make it non optional. It is not asking if I want to do it in subclasses too (related to that last). In IntelliJ I would see callers pass in “zzz”. I would have to then review the Dog usage to see if I wanted to use the parameter, given it is also doing a print with a different string (IDEs could never know my intentions re the use of that parameter).

I added a “hours” var too. I mean versus Shane Engelman’s GH version. Try to Extract-Parameter that one. PyCharm 5.0.1 does nothing at all. Weird.

There are many other refactorings that are weaker than their equivalents in IDEA. There are many refactorings that are missing too:

Solution (that only the JetBrains folks can do)

PyCharm (etc), as well as the AST it has of the parsed source, needs to retain type and usage information from the last invocation of the application/service/solution. Better still, it should glean type and usage information from invocations of tests. Python wouldn’t be Python if it has static typing adornments, but JetBrains could make perfectly hidden type info, and it would be a significant boost to PyCharm’s capabilities. The downside is the programmer using PyCharm has to run that test suite. Most likely, there would a social contract for you to run it at intervals as you are working on the codebase.

If that meta info were collected, then hovering over a variable name could cause a tool-tip that would say what type it is. Of course duck-typing might mean that a variable used at a certain scope may have one of a number of alternates of types (again collected from test runs).

A final reminder

If you’re not refactoring towards “most stable”, then your solution isn’t going to be maintainable in the future.

If your IDE does not have refactoring support it is pretty easy to predict that refactoring is a rare event for your team.



Published

December 12th, 2015
Reads: 324

Syndicated by DZone.com
Reads:
4412 (link)

Comments formerly in Disqus, but exported and mounted statically ...


Sun, 13 Dec 2015Andrey Vlasovskikh

Thanks for your analysis! I've filed two issues based on your notes: PY-17957 and PY-17958. I agree that PyCharm still lacks many refactorings IntelliJ offers for Java (like the ones shown in the video). We will work on that. In PyCharm 4.5 and 5.0 we added the bulk move refactoring that traces the dependencies between moved functions, the change signature refactoring, quick fixes to convert methods into static methods or functions. Refactorings is still an area for improvements.

PyCharm can collect run-time type information during debugging. The option to enable it is "File | Settings | Build, Execution, Deployment | Python Debugger | Collect run-time types information for code insight". It's off by default so not to slow the debugger down. We use this information only for code completion and tooltips at the moment since we cannot collect all the possible types of a parameter, only those passed during the run.

We also use static analysis for determining the types of parameters. For functions that are invoked locally we infer types based on these invocations (again, only for code completion). We also infer so called structured types for parameters. These types are sets of attributes accessed in the function body (we use them for inspections as well as for code completion).

Sun, 13 Dec 2015paul_hammant

Well as usual you guys are a couple of steps ahead, Andrey. I think that a good XP/lean/CD team will really trust their tests to represent every production scenario for the code. Re: "we cannot collect all the possible types of a parameter" .. as long as the developer is aware they would much rather have a 99.5% inferred type map, than not have it because there are some edge cases left. Maybe you can allow it for projects that are 99% covered (or more). It is the same situation as when you moved the "reindexing" dialog, to the bottom right status bar (and background) in 2008/9. It was such a popular move - and you guys worried whether it would have unintended consequences.

While we're chatting - can you make a WindowsExplorer replacement (2-pane) that works on the Mac, and something that makes "widen" (https://paulhammant.com/2014... for all apps on MacOS. Ok Ok, those might be a bit too far. Keep doing what you do :)