Introduction to PyCharm – the Most Popular IDE for Python

Welcome to the second edition of Hands-On Application Development with PyCharm! Most programmers have the objective to build robust, high-quality software that can stand the test of time. The most important step to reach this goal is choosing the correct language. With so many languages out there, which is the best one to choose? A stellar programmer will take many things about the language into consideration. One of the most important aspects of the programming language to consider is the support tools that are necessary for the development stages. The Python programming language is rumored to enable great productivity compared to many other languages. Python’s famous batteries included philosophy embodies this idea by bundling a powerful standard library, a code editor, and a debugger. Everything is built into the language’s normal installer, which is available from https://www.python.org. There’s just one small problem, at least for me – Microsoft.

I know what you’re thinking. You’ve just mentally prepared yourself for a protracted rant from one of those Unix/Linux guys complaining about the big, bad evil that is Microsoft. I’m not going to do that because I’m not sure I’m a Linux guy. I mean, I do have an awful lot of cargo pants in my closet. I can’t help it. They’re just so roomy and you can carry all of your stuff without dragging a bag around with you. I’ll also admit to having a great many T-shirts with emblems, logos, or statements that maybe only 5% of the people I encounter will understand. These T-shirts are very funny, but the only grins I get are from my colleagues. The more I think about it, I’m not a Linux guy. To me, Linux is a tool. Sometimes, it’s the right one, but sometimes, it isn’t. Since I’m not a Linux fanboy, that can’t be the reason for my statement that Microsoft is the problem. The real reason is quite the opposite. About 30 or so years ago, Microsoft did something massively right. They created the first really good commercially available integrated development environment (IDE).

In truth, it may have been more than 30 years ago, and there may have been others before it. However, many “senior developers” in the software business today got their start with a Microsoft product called Visual Basic (VB). OK; this is the part where the language snobs sneer and hold their noses as though they were just presented with a plate of Brussels sprouts, or maybe a dirty diaper, but let’s reel it back in. 30 years ago, most people rocking home computers only had a handful of options. Beginners All-Purpose Symbolic Instruction Code (BASIC) shipped with just about every computer made from 1978 forward. It was an age when not even Apple had a graphical user interface (GUI) on their operating system (OS). That didn’t happen until 1983 when Apple released Lisa. We had mice, and we could create programs capable of working with pointing devices, but the OS didn’t have a windowing system. They didn’t need a windowing system because back then, computers could only run one program at a time.

Writing desktop software for computers that lacked OS-level support for Windows was hard. There were no software development kits (SDKs) or application programming interfaces (APIs) to handle any of the heavy lifting. Writing software was mostly an exercise in tedium. You had to write hundreds of lines of box-drawing boilerplate code in a tool that was barely better than Notepad. Then, one day in 1991, the year I graduated from the University of Oklahoma, it all changed.

Microsoft released a version of BASIC that included the ability to create desktop GUIs right there in the development environment. They called it Visual Basic. The first versions ran in Microsoft’s Disk Operating System (MS-DOS), but later, we got support for Windows, Windows 2, and then Windows 3.1. Windows 3.1 was significant because that’s when we got true multitasking if our PC was equipped with an 80386 processor. PCs were no longer limited to running one program at a time, and the Windows OS made mouse-driven interaction ubiquitous.

Things got interesting with VB. Instead of coding an interface, you drew the interface. The IDE included a palette of components and a window. You could draw buttons, text boxes, and anything else you needed, directly onto the window. After you drew them, you would then “wire them together” with event handlers. What you drew was what showed up when you ran the program. The VB user interface (UI) was ultimately carried over into Microsoft’s Visual Studio. Even today, Visual Studio 2022 continues with the same features that were so groundbreaking in 1991. Figure 1.1 shows the toolkit used to draw visual UIs for Windows:

Figure 1.1: The Visual Studio IDE originated as a product called Visual Basic in 1991. It defined the standards for what a good IDE should be

The VB3 IDE that began my career introduced even more ground-breaking features that my smug, cargo-pants-wearing Unix colleagues could only dream of. They were still fighting over vi’s superiority over Emacs, or vice versa, depending on whom you asked. Meanwhile, VB3 had colored syntax highlighting, support for editing multiple files, a graphical interface editor for drawing buttons and other screen widgets, and a visual programming tool that tied code, events, and GUI elements together. It had a debugging system you could use by simply clicking a line number. Doing so would create a red dot – a breakpoint in the code where the execution would stop during a test run, allowing the developer to inspect the state of the running program. It was pure coder nerd-vana! Love them or hate them, Microsoft’s VB IDEs defined what IDEs are supposed to be today. Nobody who has learned to code using a Microsoft IDE, whether it be a legacy language or a modern one, is willing to accept anything less than that experience.

With every language that I’ve learned since, the first thing I always do is find the very best IDE available that offers those features I can’t live without. When I started working with Python 3 about six years ago, I found PyCharm. I used it to perform a full re-write on a complex software-as-a-service (SaaS) product, which took me about 18 months to complete. It was trial by fire. In this book, I intend to share what I learned, complete with scorch marks.

Throughout this book, we will be learning about the general interface of the PyCharm IDE, along with customizations and extensions to help you adapt your tools to the kind of work you’ll be doing with Python. This first chapter discusses the merits of IDEs in general. I’ll provide a comparison of the most common tools used for Python development. Some of them are very good while others, despite being widely used, are fairly primitive.

We’ll cover the following main topics in this chapter:

• The purpose of PyCharm as a Python IDE and some notable details on its developing company, JetBrains
• The usage of PyCharm within the community and a breakdown of which professions tend to utilize PyCharm the most
• A comprehensive outline regarding the advantages and disadvantages of using PyCharm, in comparison to other Python editors/IDEs
• The differences between the Professional and Community editions of PyCharm and the additional functionalities that the paid edition offers

On the other hand, if you have already decided that PyCharm is the Python IDE for you, feel free to jump to Chapter 2, Installing and Configuring PyCharm, to go through the installation and registration process. If you have already downloaded and successfully set up PyCharm on your system, you might want to begin at the second section of this book, starting from Chapter 3, Customizing Interpreters and Virtual Environments.