IDEs For Python

You can get started with Python using IDLE or the command line, but to be productive you need to adopt an IDE – Integrated Development Environment. An IDE makes it easy to enter and edit programs. The editor usually offers syntax coloration and completion of possible keywords and variables. You can run a program with a single click and create projects which have multiple files. More importantly, an IDE generally has a visual debugging option where you can run your program and have it stop at breakpoints so you can examine what it stored in variables.

If you haven’t used an IDE then once you get used to it the increase in productivity will be a surprise. There are many who will advise you that you need to work using the command line and use a simple editor – Emacs or Vim say – but this is a hard way to work. You should know how to use these basic tools to craft a program but using them for everyday programming is like trying to code without a computer. A smart programmer makes use of every tool they can get and an IDE makes things easy.

Picking an IDE is a matter of personal taste. My own choice, as stated earlier, is VS Code, Visual Code Studio. While it isn’t as powerful as Microsoft’s subscription-based Visual Studio, which has strong support for Python, VS Code is free and supports Python and several other languages. It is an active open source project that brings frequent improvements. You can find out more about VS Code and Python in Appendix I.

Alternatively you can opt for JetBrains Pycharm, which is available in an open source community edition or a professional paid-for edition. If you already use Eclipse then the PyDev plugin is worth considering. Another choice is Jupyter. This provides the ability to interweave Python code, graphics and text to create an interactive notebook. It is particularly popular in science, technology and data science but it is probably not a good place to start.

Pythonic – The Meta Philosophy

There are many programming philosophies inside the Python community – object-oriented, aspect-oriented, functional programming and so on – and you can’t expect everyone to agree what is the best way to do something. However, as well as general approaches to programming, there is also a meta philosophy that is attached to Python, which is both good and bad. The idea is often expressed as code should be “pythonic”.

Pythonic is usually taken to mean writing code that works in a way that is idiomatic Python, that is, using the facilities in Python and not writing Python as if it was Java or C++ or any other language. This is a good idea, but often it is used as a criticism - “Your code may work but it isn’t very Pythonic” or “Your code is unPythonic”. When leveled against a beginner, or a new convert from another language, this can seem like a statement that the newby isn’t “one of us”. If you are going to criticize a Python newbie’s code, don’t. Instead point out how Python has a better way and leave the “unPythonic” unspoken.

There are occasionally good reasons for writing code which looks unPythonic – clarity is in the eye of the beholder – and good Pythonic code is never compact obfuscated code.

There is also a well known set of principles expounded in “The Zen of Python”. You can see this by typing at the command line:

import this

It starts:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
...

All wonderful statements but they are often used to justify some approach or other without really thinking things through. One programmer’s beautiful is sometimes another’s ugly. What is simple depends on what you know – I think tensor calculus is easy, but I have to admit that I seem to be in a minority. It is important not to justify a particular approach by simply quoting one of the Zen sayings. You have to take the whole thing into account and make an informed judgment – which is a very Zen thing to do.

There is also a broader philosophy that Python is designed never to be “surprising”. That is, if you can guess how it should work then that is how it should work. Things should work as a reasonable programmer would expect them to. This is a good philosophy and one that has guided much Python development – especially the change from Python 2 to 3. However, “surprising” is another relative term.

When you start to dig into Python, things become increasingly more sophisticated and it is arguable that many a reasonable programmer would not have an expectation of what might or might not be surprising. The Zen of Python sums it up a related principle nicely:

There should be one – and preferably only one 
 --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

When working in Python it is common to implement something using a set of code constructs and then step back and look at it and realize that you could simplify it by using some Python feature that you forget when working on the initial code. This is great and it often results in code that works better and is more Pythonic.

The danger is that you will Pythonic-ise your code into something dense and unreadable. Come back in a few minutes and your mind will no longer be attuned to the problem or the expression of the solution. It won’t have had the benefit of the easy steps through which your solution evolved. Keep in mind at all times that the objective isn’t to be Pythonic; it is to be clear in your code.

In the examples in this book I have tried not to reduce them to the smallest possible statement. Indeed, some of them are broken into steps that would often be rolled up into a single, but less obvious, operation. Pythonic code is often not the best for showing how things work.

Where Next

This lightning tour of Python has attempted to give you the flavor of the language and point out the features that confuse the programmer used to other object-oriented languages like C/C++ or Java.

Now you simply have to build on this foundation by writing some programs. Python has some very good documentation to help you and, of course, this is the purpose of the rest of this book.

Summary

• Python initially looks like other languages you might know, but Python isn’t quite what it appears to be.

• In Python everything is an object. Objects do carry an indication of type, but variables are untyped.

• Variables store references to objects, not values.

• Assignment and parameter passing use reference semantics.

• Integers in Python have an unlimited number of digits.

• Strings are immutable and support slicing, like many other Python collection objects.

• There is a range of sophisticated data types. The list does the work of the array in other languages. The dictionary is essentially an associative array. The tuple is a lightweight immutable list.

• Python is different from other languages in that code indentation alters the meaning. A block of code consists of a set of consecutive statements at the same indent level.

• The for loop is a general iteration loop, i.e. it iterates over a collection of objects rather than a numerical start, stop, step range. To construct a numeric loop you would use the range() function. The only other loop provided is while.

• Conditionals if, elif and else are used to structure complex conditions.

• Pattern matching is provided for the most complex conditional structures.

• Functions are objects but beginners can ignore this and write ad-hoc scripts as if they were functions in any other language.

• Classes are objects, but beginners can ignore this and pretend they are using a classical class-based language.

• Objects have attributes, some of which can be functions.

• Inheritance works much like other languages, but class objects are directly involved in retrieving attributes.

• Modules are how Python code is packaged into larger units.

Programmer's Python
Everything is an Object
Second Edition

Is now available as a print book: Amazon

Contents

1. Get Ready For The Python Difference
     Extract 1: The Python Difference ***NEW!
2. Variables, Objects and Attributes
3. The Function Object
4. Scope, Lifetime and Closure
     Extract 1: Local and Global 
5. Advanced Functions
6. Decorators
7. Class, Methods and Constructors
     Extract 1: Objects Become Classes 
8. Inside Class 
9. Meeting Metaclasses
     Extract 1: Metaclass
10. Advanced Attributes
11. Custom Attribute Access
12. Single Inheritance
13. Multiple Inheritance
14. Class and Type
15. Type Annotation
16. Operator Overloading
17. Python In Visual Studio Code

 Extracts from the first edition

<ASIN:1871962749>

<ASIN:1871962595>

<ASIN:1871962765>

Related Articles

Creating The Python UI With Tkinter

Creating The Python UI With Tkinter - The Canvas Widget

The Python Dictionary

Arrays in Python

Advanced Python Arrays - Introducing NumPy