The day started at 9.00, and at first it was time of check-in, etc. After that, I solved one riddle by kiwi.com, and earned a discount in flights, which was a nice way to start the conference.

Then after breakfast and some networking going through the booths of the sponsors, it was time for the first talk of the day: "When bugs bite - why neglecting edge cases can kill".

Descriptors generally have to interact with attributes of the managed object, and this is done by inspecting __dict__ on that object (or calling getattr/setattr, but the problem is the same), and finding the key under the specific name.

For this reason, the descriptor will have to know the name of the key to look for, which is related to the name of the attribute is managing.

On previous versions of Python this had to be done explicitly. If we wanted to work around it, there were some more advanced ways to do so. Luckily, after PEP-487 (added in Python 3.6), there are some enhancements regarding class creation, which also affects descriptors.

Descriptors are an amazing tool to have in our toolbox, as they come in handy in many opportunities.

Probably the best thing about descriptors, is that they can improve other solutions. Let's see how we can write better decorators, by using descriptors.

Decorate a class method

Imagine we have a very simple decorator, that does nothing but returning a text, with what the original function returns:

class decorator:
    def __init__(self, func):
        self.func = func
        wraps(func)(self)

    def __call__(self, *args, **kwargs):
        result = self.func(*args, **kwargs)
        return f"decorated {result}"

class Object:
    @decorator
    @classmethod
    def class_method(cls):
        return 'class method'

If we apply the decorator to a simple function, it'll work, as expected. However, when it's applied to a class method, we can see an error:

Resuming from where we left off, on the previous post, on which we took a-first-look-at-descriptors{.interpreted-text role=“doc”}, it’s time to explore their different types and how they work internally.

In Python, almost everything is represented with a dictionary. Objects are dictionaries. Classes are objects, hence they also are contained into a dictionary. This is denoted by the __dict__ attribute that objects have.

There are two types of descriptors: data descriptors and non-data ones. If a descriptor implements both¹ __get__() and __set__(), it's called a data descriptor; otherwise is a non-data descriptor.

Descriptors are one of the most powerful features of Python. The reason why they're so powerful is because they enable us to control the core operations (get, set, delete)¹, of an attribute in a given object, so that we can hook a particular code, controlled by us, in order to modify, change, or extend the original operation.

A descriptor is an object that implements either __get__, __set__, or __delete__.

As of Python 3.6+² the descriptor protocol entails these methods:

The proposal of my talk titled "Discovering Descriptors", was accepted for the next edition of PyCon CZ, in Prague, Czech Republic. Although the schedule is not yet ready, this talk will most likely be on June 8th.

The first two days of the conference (June 8th and June 9th), will be for talks, whilst the last one (Saturday, June 10), will be for workshops (sprints).

This is another interesting opportunity to share and learn from the Python community, as it was last year when I presented at EuroPython 2016. On this occasion, I plan to post an entry with the events, per each day of the conference.

This is another of the new interesting things that Python 3 has. Time ago, it was somehow tricky to work with decorated functions, because the decorator replaced the original object, and its behaviour became hard to reach.

So, for example, we all know that the following sentence:

@decorator
def function():
    pass

It’s actually syntax sugar for:

def function():
    pass

function = decorator(function)

So, if for some reason, we need to work both with the original and decorated functions, we required tricks such as different names, something like:

Last Thursday November 17, 2016, there was a Python meetup in Barcelona¹, with a set of interesting talks.

The first one was hosted by two representatives of the government of Catalunya, and Barcelona city, and they presented the technical challenges they are facing, and the new stack proposed for oncoming projects. In this regard, it was interesting to see how they have lots of legacy applications written in J2EE, with Java frameworks, that are outdated, difficult to maintain, and they mentioned the idea of migrating them to new, more modern technologies. In this sense, there are already projects in progress, and they chose Python + Django for the migration and re-implementation of the legacy systems.

The next Saturday 10 of September, I will be presenting my talk "Clean Code in Python", as presented in the previous EuroPython 2016, at a local Python event in Córdoba, Argentina¹².

The following week, I will be attending a local architecture meetup (arqconf), on which a talk³ about OpenStack will be hosted, explaining how they work in a distributed fashion.

I look forward to enjoying both events!

I had the great experience of presenting at EuroPython 2016. My talk entitled "Clean code in Python", was about good development practices, down to low-level design (with code examples), for Python. The idea of the talk, was to present the "pythonic" approach for writing code, and how do general concepts of clean code apply to Python.

These examples might be useful for beginners, developers experienced in other languages coming to Python, and people using Python for scientific applications. The examples could also be helpful for senior developers, because they remind real situations that might appear in pull requests, while doing a code review.