Clean code in Python, second edition has been published, and here are the main highlights!
The main change is that the book has been updated to Python 3.9. The previous
edition was started when Python 3.6 was new, and by the time it got published,
Python 3.7 was just recently released. Since then, a lot has
changed in Python and the book addresses the new features.
In our profession, attention to detail is of utmost importance. Any good software engineer understands that details matter a lot, as they make the difference between a working unit or a disaster1.
This is why clean code is not just about formatting or arranging the code. It's neither a foible. It is instead, paying attention exactly to those details that will make a big difference in production.
Let's see some examples of this in Python.
Last weekend an amazing edition of Python San Sebastián took place. Here are the main highlights of what the conference looked like to me.
Friday starting with a workshop on the morning that took place in the university of informatics of Basque Country. It was a workshop about machine learning, with Python.
The content was great, and enlightening. It's a very interesting topic, and presented with the main tools to work in Python: Jupyter, numpy, pandas, etc. Promising start.
Let's revisit the idea of generators in Python, in order to understand how the support for coroutines was achieved in latest versions of Python (3.6, at the time of this writing).
By reviewing the milestones on generators, chronologically, we can get a better idea of the evolution that lead to asynchronous programming in Python.
We will review the main changes in Python that relate to generators and asynchronous programming, starting with PEP-255 (Simple Generators), PEP-342 (Coroutines via Enhanced Generators), PEP-380 (Syntax for delegating to a Sub-Generator), and finishing with PEP-525 (Asynchronous Generators).
This is an opinion I sometimes remember when seeing some code. Don't take it as a strong advice, or a rule, but instead as a general guideline that might help you to improve the code slightly.
On this post I will share a tiny and opinionated argument about why there are usually better things to do in the code instead of just pass.
Disclaimer: I am not saying that pass should be banned from the language, or that is an anti-pattern, or a bad idiom. Nothing like that. If that were the case, it wouldn't be a keyword (and we know how few keywords Python has, and how hard it is to introduce a new one, so it's there for a good reason).
Summary of the last days of talks at EuroPython 2017, and the two days for sprints.
The keynote for this day, titled The Different Roads We Take, made an interesting point by stating that the way we evaluate ourselves is non-linear, and coming from different backgrounds, gives everyone of us different a set of experiences and skills.
Afterwards, I moved to an advanced workshop called A Hands-on approach to tuning Python applications for performance, on which we covered several profiling tools for Python code, with pros and cons of each one (performance, overhead, simplicity of use), and some optimization techniques, running the profiling code after each improvement was made, in order to see the difference.
A summary of the first days (from day 0 --Sunday to day 3 --Wednesday), of EuroPython 2017.
Once again, like last year I volunteered for the beginners' day on Sunday, right at the dawn of the conference. It was another great opportunity to share knowledge and experience about Python.
In particular this time I was lucky enough to work with a group of mathematicians who used Python for data science, so I learnt about these concepts, and we worked a bit with Pandas for processing numbers.
The third day of the conference was hosted on a different venue, the Czech Technical University of Prague.
I signed up for two workshops: search for fun (and profit), and Effectively running python applications in Kubernetes / OpenShift.
They were both great, and left me with lots of interesting topics for research and do further work.
The first one walked through the workings of
elasticsearch-dsl-py,
which was great not only because the explanations were superb, but also
because there is probably no better way to review this than from the
author himself. I was already experienced with the library, since I've
used, Elasticsearch with Python, but even though, this workshop gave
me a deeper understanding of the concepts behind it (there was a lot
about the internals of Elasticsearch, how it works, its configuration,
concepts of information retrieval, etc.), so I got new ideas. On the
practical side, I'll check this
project.
Summary of the second day of Pycon CZ 2017.
At 10:00 it was time for the first talk: a keynote titled What lies ahead? Python's future strengths and main challenges. It was a great talk, I really enjoyed the remarks of a Pythonista remembering thins from early Python conferences. The main conclusion that I took from the presentation was that, even in the early days there were some really tough challenges to overcome (for example the use of indentation, scripting, etc.), and Python surmounted it. These challenges were, perhaps even bigger than today's ones (debates about Python 2/3, etc.), which makes me think that current issues don't jeopardize the future of Python at all, so the community and the language will get through them. Really inspiring, and engaging.
This talk was presented at PyCon CZ 2017 and EuroPython 2017. Here are the references and resources for the presentation.
The code used for the talk, is available here and contains some explanations along with the examples.
This is the recording of the talk presented at EuroPython 2017.
{{ youtube(id=“TAuC086NNmo”) }}
To learn more about descriptors, you could check some of the following references, used as base for the talk: