It looks like there are a lot of opinions or assumptions about unit tests and code coverage, most of them confusing of biased in several ways. For example, I've heard or read things like "this is fine, it has X% coverage", or "checking for coverage on pull requests doesn't help", or "dropping the coverage level is not an issue", and many more of the like.

This article aims to shed some light on the issue of unit testing with and code coverage. Hopefully by the end of it, we'll get an idea of which of the previous statements are right and which are wrong (spoiler alert: they're all wrong, but for different reasons).

The third day of the conference was hosted on a different venue, the Czech Technical University of Prague.

The workshops

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.

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.