Refuse the temptation to pass

This is an opin­ion I some­times re­mem­ber when see­ing some code. Don’t take it as a strong ad­vice, or a rule, but in­stead as a gen­er­al guide­line that might help you to im­prove the code slight­ly.

On this post I will share a tiny and opin­ion­at­ed ar­gu­ment about why there are usu­al­ly bet­ter things to do in the code in­stead of just pass.

Read more…

Beyond coverage

It looks like there are a lot of opin­ions or as­sump­tions about unit tests and code cov­er­age, most of them con­fus­ing of bi­ased in sev­er­al ways. For ex­am­ple, I’ve heard or read things like “this is fine, it has X% cov­er­age”, or “check­ing for cov­er­age on pull re­quests does­n’t help”, or “drop­ping the cov­er­age lev­el is not an is­sue”, and many more of the like.

This ar­ti­cle aims to shed some light on the is­sue of unit test­ing with and code cov­er­age. Hope­ful­ly by the end of it, we’ll get an idea of which of the pre­vi­ous state­ments are right and which are wrong (spoil­er alert: they’re all wrong, but for dif­fer­ent rea­son­s).

Read more…

PyCon CZ - Day 1

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

Then af­ter break­fast and some net­work­ing go­ing through the booths of the spon­sors, it was time for the first talk of the day: “When bugs bite - why ne­glect­ing edge cas­es can kill“.

It was a great talk, a case for soft­ware en­gi­neer­ing in gen­er­al (it’s not Python-speci­fic, which is what makes the top­ic more in­ter­est­ing). The best thing I liked about the talk was the re­mark­s, and the idea of shift­ing the mind­set when it comes to de­vel­op­men­t, so we should do some “neg­a­tive think­ing” in the form of what can go wrong with this? How can this fail?, and such. It’s im­por­tan­t, be­cause this is crit­i­cal in or­der to make ro­bust soft­ware. Most prob­lems I have seen on soft­ware bugs were re­lat­ed to some op­ti­mistic think­ing, and even worse, op­ti­mistic unit test­ing, in the way that de­vel­op­ers on­ly test for hap­py-­path sce­nar­ios, with­out think­ing all sort of things that can go wrong.

Af­ter­ward­s, was the time for the talk about par­al­lel pro­cess­ing (poor per­son­’s par­al­lel pro­cess­ing), which was fine. Then I spent some time tack­ling some of the chal­lenges spon­sors had avail­able, so I did some cod­ing and re­cap of the events so far.

Then I listened to a talk about wolfcrypt which is a tool for crypto in Python. The talk introduced some crypto concepts (symmetric crypto, public key, etc.), which was good. Most of the questions revolved around comparison with other tools in python (default libraries, pycrypto, etc.).

Then it was time for lunch and do some more cod­ing, and the next talk I at­tend­ed to was called “should I mock or should I not?“, which I liked very much and gave some food for thought.

Then it came one more talk, af­ter which it was time for mine, so I pre­sent­ed clean code in Python. There were some in­ter­est­ing ques­tion­s, and the en­tire pre­sen­ta­tion went rel­a­tive­ly quick­ly.

Once the talk ses­sions were over, there was one last track for light­ning talk­s, which are al­ways su­per en­ter­tain­ing.

Af­ter the fin­ish of the first day, I at­tend­ed the speak­er’s din­ner, which was a nice op­por­tu­ni­ty to net­work with the com­mu­ni­ty, which is al­ways great.

Look­ing for­ward to some more in­ter­est­ing talks to­mor­row, and to see the re­sults of the chal­lenges.

The __set_name__ method for descriptors

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 rea­son, the de­scrip­tor will have to know the name of the key to look for, which is re­lat­ed to the name of the at­tribute is man­ag­ing.

On pre­vi­ous ver­sions of Python this had to be done ex­plic­it­ly. If we want­ed to work around it, there were some more ad­vanced ways to do so. Luck­i­ly, af­ter PEP-487 (added in Python 3.6), there are some en­hance­ments re­gard­ing class cre­ation, which al­so af­fects de­scrip­tors.

Let’s re­view the prob­lem, the pre­vi­ous ap­proach­es to tack­le it, and the mod­ern way of solv­ing it.

Read more…