Some realizations and decisions I have come to in the last week or so…
It appears most Python programmers work in Linux. Many Python learning resources seem to assume a Linux environment. One of my reasons for adopting Python was the fact that it’s open source, unlike MS Access wherein is all my previous coding experience. On the other hand, I need Windows 7 running natively on my laptop so I can take full advantage of all the functions of my two USB scanners. To save my life, I couldn’t get these to work on Linux, either running natively on my laptop, or with Windows 7 in a Virtual Box VM. I have therefore switched my Python coding to Linux Mint, running in a Virtual Box virtual machine under Windows 7. I have all my code projects in Dropbox, which works great in Linux and Windows 7, and a selected few also on GitHub.
I have come to the conclusion that, going forward, my personal coding projects will be in Python 3. If I run across a learning opportunity that requires Python 2.x (for example, something requiring wxPython), then I will revert back. On that topic, this article by Jeff Knupp alerted me to the necessity of virtual environments.
Oldřich Vetešník became my first collaborator on GitHub and brought me back to the necessity of unit testing and had some helpful suggestions on basic app design, i.e., making the app itself a class. This poor soul heard loudly from Snarkoverflow (oops I mean Stackoverflow) about the undesirability of writing an app first and THEN testing it. Ouch. That was me with my CsvChamp module. Luckily Mr. Vetešník was much kinder. But I do need to get with the program regarding testing, so in keeping with that goal and my need to learn Python 3, I’ve decided to re-do CsvChamp from scratch, in Python 3, starting out with unit testing. That is my current project, and updates will follow!
Next challenge: How do I pull together the need to work in both Python 3 and Python 2, version control with GitHub, coding in Linux. Virtual environments, testing and debugging? I was using Notepad++ and IDLE alternately, and the GitHub Windows app, plus a whole lot of directory-switching in both the Windows and Linux command lines. All of these had their quirks and annoyances. IDLE is decent for debugging, but its code editor doesn’t display line numbers. How annoying is an IDE that tells me what line in my code has an error, but can’t show me the line number? IDLE also has the annoying habit of giving me blue screens of death on Windows XP (yes, there is a situation in which I have to use XP. Don’t ask). Notepad++ is a good editor but doesn’t do debugging. Regarding GitHub, the Windows GitHub app is slow, bloated and feature-sparse. I read an article that suggested many Python developers use Vim, but from the little I know about Vim it appears there would be a steep learning curve with its multitude of keyboard-based commands and all the add-ons I’d need to accomplish what I want.
Enter PyCharm. I did some research on IDE’s and decided to give this one a spin, and so far, I love it. It connects seamlessly to GitHub and incorporates virtualenv in a way that makes it easy to switch between Python 2 and 3 and maintain separate sets of libraries for each, and even lists what’s in each library set in case I forget what I installed and where. I was able to configure its text editor in the same nice colors I enjoyed in Notepad++. It displays line numbers, debugs, and even admonishes me when my coding style strays from PEP 8, among other things. It has both Windows and Linux versions. Perhaps by doing so much for me, it’s short-changing some more learning experiences, but that’s a trade off I’m willing to make to be able to focus more on getting some actual coding done, and done right.