Macbeth once asked himself, “to be or not to be a Python developer?” Many years later, some of you are asking yourselves the very same question. And if the answer is or was ‘yes’, continue reading. You will find out about the best practices you should be aware of when developing in Python.
This guidebook contains the following sections:
1. General Technological Concepts
2. Code Quality
3. Performance
4. Frameworks
5. Architecture
General Technological Concepts
There is a set of general guidelines, called PEP 20: The Zen of Python, which helps developers in the development process and provides coding standards. Below, you can read and memorise all of them:
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.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
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.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!
Code Quality
The above guidelines are not just Python-related – they can also be applied to other programming languages. Moreover, some of them are applicable outside the tech industry, and this makes them future-proof.
Let’s talk strictly about choosing and using code style guides – personally, I prefer PEP 8. And you know what? So do most Python enthusiasts from SoftwareHut. You can find all of its rules and their descriptions on this website.
These standards may seem like a pair of handcuffs, but they are not. I prefer to think of them as a way to find common ground with established rules. On the one hand, they describe some entirely distinct things, but on the other hand, there is room for choice in some areas. And that’s when we choose the solution that is a better fit for the particular project.
If there is a case that’s not covered by PEP8, I check the Google Python Style Guide.
What about formatting the code? If you want to focus more on its intention, not on its style, check Google YAPF. It’s a formatter for Python files and dramatically reduces the time necessary for formatting the code.
Performance
Try to follow this simple plan when developing a new functionality:
- Make it work.
- Make it readable.
- Make it fast (optionally).
These steps help you to split your work into milestones. You shouldn’t have any problems understanding the first two bullet points – interpret them as required. The last one, on the other hand, is optional because it may not be the best use of resources when optimising the code. It is mainly applied if you are basing on the premise that a particular piece of code would be an application bottleneck.
Do you know what the Global Interpreter Lock is? If you don’t, get to know how it works and about the limitations it creates.
Frameworks, libraries and tools
Always think and look around before implementing more prominent parts of the project. Who knows? Maybe there is already a solution you could use instead of writing it from the beginning. The second way to get something done faster and better is to ask the Python community about a specific project. But remember to make your question wise and easy to understand.
Last but not least: remember to always update requirements.txt to reflect the current state of frameworks/libraries used in the project.
Architecture
If you devote some time to create good project architecture, it can give you 1000% Return on Investment in the future. Why? Because there aren’t many things worse than a poorly designed structure over the course of a project. Don’t hesitate to ask your colleagues if you have any doubts. This could save many work hours and hair on heads down the road.
