Initial Impression on Atom.io Editor
I had endured enough abuse from PyCharm. There were many great things about it; there were several unacceptable “features” that irritated me.
- It crashed. A lot. I suspect it was actually killed by OS X because I’d find console system entries about pycharm using too much processor for too long. While I’m pretty easy going about apps crashing, after several times (5 times in one morning) losing very critical work I started getting very paranoid. It seemed to be related to HTML template files since this was where the lost work showed up. Or, rather didn’t show up since it was lost.
- It was slow. Everything was slow. And is was a resource hog — like most of Jetbrains software. Naturally, this is a result of the many features — yet it was so bloated it it really bothered me. It’s usually one of the highest CPU and Memory entries in Activity Monitor.
- Could only run my paid-for, licensed copy on one computer at a time. This, to me, was horribly unacceptable. It didn’t happen often, but occasionally I needed to debug both the server and the client on two different machines. I’d launch it on my Mac and also on my Windows box and soon would get a popup on one or the other regarding the license conflict. Their answers to me on this were blunt. Sorry, dude — license two copies. Screw you.
- Flashing windows task bar and OS X bar — no idea why. And they won’t fix it. So annoying. What was worse it that sometimes the PyCharm instance would pop to the front as I was typing in another app and suddenly I’m typing in source code. Sure, Cmd Z, but still…
As for Atom.io, in short: I love it. It’s fast, highly customizable and has only crashed on me once thus far, and I suspect it was the fact that I regenerated the ctags file while the editor was open.
While I will probably do another write-up on the things that make it a great editor, I wanted to list a few of the concerns that I have in the hopes of getting some feedback on tips for solving these issues. I’m sure some of these might already be possible; some might be an easy customization. Note also that all of this is within the context of using Atom.io — a generalized editor — for Python development.
Parameters from Docstrings
PyCharm did a pretty good job of presenting the parameters for a method, especially if there was a docstring. There doesn’t appear to be a way to do that in Atom.io.
Why this important: Discipline. It’s good practice to include the named parameters, and I’ve gotten into this practice. It’s more difficult in Atom since you have to jump to the method to look. Easily done, and I’ve started simply copy-pasting the signature and filling out the details, yet it’d be nice if the editor could present (somehow) what the signature is. I understand that this is an editor and not an IDE and the “auto-complete” is simply a textual matching of the letters typed, and not contextual to the object type of method.
Docstrings and Parameters
Speaking of docstrings and parameters, typing triple quotes and pressing enter in PyCharm automatically generates a docstring template complete with the parameters.
Why this is important: Again, discipline. It’s good practice to include a docstring for each method call, and darned polite. Making this less painful encourages good behavior. Your co-workers thank you.
Launch Flake8, or Unit Tests
Part of what makes PyCharm so bloated and slow is the instant syntax and contextual feedback. Too instant, sometimes — yes, I know this is an error, darn it. I’m not done typing.
I don’t really want immediate feedback always, but when I’m ready to try something out I’d love to be able to launch flake8 or unittest right in the editor. Then I’d love to be able to click on the output and have the editor take me directly to the offending line where I’ve transgressed some PEP8 rule.
Why this is important: It speeds up the process and makes me more likely to run my checkers more often. As it stands I simply keep a command window open and constantly run tests and flake8; having it right in the editor, however, would make it easier to resolve issues.
Add Unit Test
Now I’m just getting crazy, but hear me out. I want to be able to automatically add a unit test that fails when I create a new method.
No editor I’ve seen yet can do this and it’s not really an editor “thing”. But I’d like to have the editor understand the keyword pattern and how to launch the utility to update the tests. Here’s how it would work:
- The module would identify an associated unit test module in the docstring.
- A class would identify an associated unit test [module and] class in the docstring.
- A method would identify an associated unit test [module, class] and list of unit test names. (See below)
- An editor hot key would instantly create the unit test module, class and test methods if they do not already exist; test methods would simply be self.fail(‘Auto create unit test’)
Why this is important: You’re getting it — discipline. I’m lazy, but convinced at the value of certain techniques. They tend to save me time in the long run, thus helping me be lazy.
This doesn’t necessarily need to be an integrated feature of the editor, but he ability to launch a utility that would do this would be great.
“But that’s not TDD,” I hear you saying. You should write your tests first and then write the code. Wisen up. I love TDD, but it’s rare that I write up a complete list of tests before the code. True, I will write up unit tests skeletons that match specific features or behaviors, but especially when defining models and model methods or proxies I will write the methods first and then the tests — and too often I forget to write the tests.
But, while I’m writing the method I often do think of how I’d write the test to verify it. The ability to define the test would at the very least yank me to fill in the test details if it will automatically fail.
And yes: I don’t like writing the tests in the same file. Too cluttered.
I currently have 5 major projects that I work on and I find myself switching between them often. While it is easy to open a “project” (aka, a folder) it’d be nice to keep named references to each.
Class and Method Tree
I love when IDE’s provide a panel with the classes in a file and the methods of those classes. Often that’s all I need — a hint as to what a method name is or class name. There is no way to do this that is truly helpful. Sure, there is Cmd R — but this, again, simply lists the strings and it’s not filtered by any sort of type. It’s all but worthless given all the clutter.
A programmers editor I used in the 80's had a feature where it “collapsed” the entire source by indent position. I could instantly get the list of C functions this way. For Python this would work great, especially if you could toggle or cycle through the indent level.
Object Contextual Information
I like the “auto complete” and the ability to “drill into” a particular method once the ctags are generated with Alt Cmd Down. But it’s not truly Python aware as much as it’s simply text string pattern matching. It’s a start; it’s far from what I’d like to see in my editor.
As with having a class and method tree, I’d love auto complete to understand context. I fully realize we’re getting into bloated IDE territory, but consider this: Python has a terrific ability to inspect classes. It’s super easy to get a list of methods, properties, etc. And it’s easy to determine the named parameters for a method. Even the docstring is available.
It should be fairly easy for the editor to track a few things. (By the way, PyCharm also sucked at this, and one had to provide type “hints” constantly.) The auto-complete list could be constrained to context under certain conditions:
- If a classname has been typed with a ‘.’: MyClass. — the list of strings provided could be constrained to only those that exist within the context of MyClass. It doesn’t even need to be anything special — all attributes. Fields, methods, properties — as long as they are only within the class.
- If no context is known presume the immediate context initially. Typing “_do_this” should first present any matching strings within the current method, then look within the current class, module, and then a more global context.
- Consider Case: If a symbol starts with an upper case it’s probably a class. Only initially presenting matching patterns with the known classnames.
Verify a module/symbol is available
A bloated IDE loads and maintains a massive symbol table, and as one types a class or method call it provides immediate feedback as to whether or not it is defined. In PyCharm, pressing Alt Enter over an unknown symbol may allow automatically generating the import statement.
I wouldn’t even need all that: But I would like to be able to verify that a symbol has been imported or is visible. An Atom package that would allow me to highlight a word and verify it would be nice. (Yes, so would a Ferrari, but meh.)
Python Package Management
I could talk a lot about this category — PyCharm didn’t do so well either. But there are two features that would be great to have right in the editor
- Instant “pip” listing that reveals updated packages. Yup, ‘spose it’d need to be virtualenv aware.
- Generate or update a “requirements.txt” document. It’s such a little thing that I often forget about it. But I’ve gotten in the habit of following the Two Scoops of Django approach to Django project setup and have a “requirements.txt” set of files. And invariably I update or install some package with pip, continue on with development, and totally forget to update the requirements documents. But, I’m sure I’m the only one.
I don’t see myself trying any other editors for the moment. There is so much I like about this one. But I do see myself researching to find out if there are already features or packages that address some of these, or if the package could be easily created.
What I have loved about Python, and Django, is that they are so productive. One can quickly and easily build and deploy things that took much longer in previous environments. That said, being a run-time interpreted language, and the lack of strongly typed parameters introduce some liabilities. Disciplined use of the many good checkers and tools helps to mitigate against certain types of problems.
Unit tests and wrappers such as flake8 help tremendously to ensure that modules are properly vetted. A development environment also must provide tools to ensure that code is properly mapped out.
I see this category of the development process as a critical feature the bloated IDE vendors provide. While there can be a false sense of security, they do provide instant feedback that helps to avoid problems; even if the unit tests catch the problem, catching it earlier is less costly.