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.

Slides

Video

This is the recording of the talk presented at EuroPython 2017.

{{ youtube(id=“TAuC086NNmo”) }}

References

To learn more about descriptors, you could check some of the following references, used as base for the talk:

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.

After watching a talk about code review¹, from the last EuroPython, I got some ideas that I'd like to summarise.

The first one is a point I made on my talk about clean code in Python, about running style checks (PEP-8, for example), automatically as part of the CI. This has several rationales, the first one being that it's the sort of thing machines should do, and not humans. Having software engineers reviewing the tabs, spacing, and such, is just a wasted effort (not to mention, wasted money). As I mentioned on the conclusions during my talk, we should focus on the readability of the code in terms of the logic, by asking ourselves things like "does this code make sense?", rather than "is the space before the comma correct?". Remember, code is for humans, not machines, it's a means of communication with the development team.

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: