Checking Python files with Vim

Vim is an ex­cel­lent ed­i­tor, and mas­ter­ing it leads to more pro­duc­tiv­i­ty. Even though is very ex­ten­si­ble and al­lows to be con­fig­ured by many plug-ins I rather keep it as sim­ple as pos­si­ble, try­ing not to use many plug-ins (nei­ther pack­agers like Vun­dle, etc.).

How­ev­er, I do make use of an ex­ten­sion that checks Python files for er­rors, PEP8, a­mong oth­er things: flake8. Be­cause I do not use plug-in plat­forms for Vim, I in­stall just this one man­u­al­ly, by mak­ing the com­mand flake8 avail­able sys­tem-wide [1].

Then the in­stal­la­tion is as sim­ple as down­load­ing the project and coy­ing the files in­to the ~/.vim/ft­­plug­in/python di­rec­to­ry. Make sure you have the fol­low­ing line added on your ~/.vim­rc:

filetype plugin indent on

The fea­tures I use are main­ly the syn­tax and PEP-8 com­pli­ance check­er­s. It can al­so warn you about un­used im­port­s, and cy­clo­mat­ic com­plex­i­ty.

It is use­ful be­cause things like PEP-8 com­pli­ance help to have a good code qual­i­ty, and there­fore a more read­able and main­tain­able code base, spe­cial­ly on large projects with lots of files and mod­ules.

That’s al­l. For more de­tails and oth­er con­fig­u­ra­tion tips check­out my Vim set­up.

[1] Another option would be to install it on your virtual environment, but then you have to make sure to install it once per project. It is actually better, because you are not using the global system environment, but for packages like this, it should not be an issue, it’s your choice.

Alpine email client

Alpine is a soft­ware I def­i­nite­ly rec­om­mend for those who like min­i­mal­is­tic ap­pli­ca­tion­s that go straight to the point in or­der to get the things done. It’s an email clien­t, with no GUI, which al­lows me to read emails bet­ter than by means of the web page [1] with­out any dis­trac­tion­s, fo­cus­ing on what is just im­por­tan­t. It is al­so great that shows on­ly the text (the rel­e­vant part of the email) and it can fol­low the links by launch­ing the de­fault brows­er.

It is sim­ple, fast and per­fect­ly suit­able for check­ing my old in­box with week­ly lists up­dates. It’s in­her­it­ed from an old pro­jec­t, called pine, and in Fe­do­ra it can be in­stalled by:

sudo dnf install alpine

Then you just need to con­fig­ure the email ac­count set­tings (one last time to vis­it the page, but that would be the last :-) and you’re ready.

[1] Not for gmail but from another older account I have

Libvirt networking libraries

Fe­do­ra 21 work­sta­tion seems to come with a lot of vir­tu­al­iza­tion fea­tures and most of the lib­virt li­braries in­stalled. I on­ly had to add the KVM vir­­tu­al-­­man­ag­er which is the KVM ap­pli­ca­tion I am more fa­mil­iar with. How­ev­er, the new ver­sion of the lib­virt* li­braries have net­work­ing fea­tures that are great for the da­ta cen­tre en­vi­ron­men­t, but maybe not the best op­tion ­for a par­tic­u­lar work­sta­tion, so I added the fol­low­ing pack­ages in or­der to set up an eas­ier net­work con­fig­u­ra­tion for my lo­cal vir­tu­al ma­chines.

sudo dnf install virt-install libvirt-daemon-config-network

In or­der to re­flect the changes and start us­ing the new fea­tures, we need to restart its ser­vice:

systemctl restart libvirtd.service

Af­ter that, when cre­at­ing a new vir­tu­al ma­chine, the NAT op­tion is en­abled, and the vir­tu­al ­man­ag­er with han­dle the NAT or bridg­ing con­fig­u­ra­tion au­to­mat­i­cal­ly, which al­lows me to de­ploy new ­ma­chines faster.

Do not import *

It is well-­known among Python de­vel­op­ers (or at least, it should be), that is a bad idea to im­port ev­ery­thing from a mod­ule, for ex­am­ple by do­ing from <mod­ule> im­port *.

The idea on this post, is to high­light and gath­er the rea­sons why this is a bad prac­tice, in or­der to col­lec­tive­ly i­den­ti­fy many un­de­sired ef­fect­s. How­ev­er, with­out los­ing prag­ma­tism, in case there are some odd rea­sons why this might be ac­cept­able, I will al­so men­tion them, if any. Let’s see where we get.

  1. You do not know what you get
    An ar­bi­trary Python script may con­tain any code, and most of it will be ex­e­cut­ed when per­form­ing the im­port * part (y­ou can­not re­ly on how __­name__ is han­dled). The in­ter­face is to­tal­ly un­clear: you do not know what com­pu­ta­tions per­form­s, what ob­jects will im­port, etc. In gen­er­al is more ef­fi­cient to im­port as few def­i­ni­tions as pos­si­ble.
  2. Iden­ti­fiers ap­pear mag­i­cal­ly
    In any de­cent­ly read­able Python scrip­t, the pro­gram­mer must be able to lo­cate ev­ery def­i­ni­tion, which mean­s ­to iden­ti­fy where does ev­ery iden­ti­fi­er come from. For ex­am­ple, a vari­able named x can ei­ther be a pa­ram­e­ter of the func­tion in the cur­rent scope, a vari­able al­ready de­fined (as­signed), or a name al­ready im­port­ed (from mod im­port x), etc. ­By per­form­ing the in­cor­rect im­port, this vari­able might ap­pear out of the blue, mean­ing that I will have an x that will not be nei­ther a pa­ram­e­ter, nor a def­i­ni­tion nor a de­clared im­port. This mean­s, I can­not ­track the ori­gin or x. The sit­u­a­tion gets worse if there are not one, but many im­port * state­ments. De­bug­ging be­comes a night­mare.
  3. Names­paces are one honk­ing great idea — let’s do more of those!
    Straight from the Python zen [1]. By im­port­ing ev­ery­thing from a mod­ule, the ben­e­fits of the names­paces are some­how lost. In­stead, ev­ery­thing (or a lot of things), might get to be called the same, mess­ing with the cur­rent scope. More­over, new im­port def­i­ni­tions might over­ride pre­vi­ous ones.
  4. Ex­plic­it is bet­ter than im­plic­it
    Again, ev­ery iden­ti­fi­er that we want im­port­ed should be done ex­plic­it­ly (the * is not very declar­a­tive).

Now, so far these might be some of the main rea­sons about why im­port­ing ev­ery­thing from a Python mod­ule is usu­al­ly not a good idea. How­ev­er, in case the code at stake is just a sim­ple test­ing scrip­t, or an in­-­line sen­tence on ipython, there could be noth­ing wrong about it.

In ad­di­tion, al­though I am not a big fan of im­port state­ments in­side func­tions (some­times they are nec­es­sary, though), im­port­ing ev­ery­thing from a pack­age with­in a func­tion is not a big prob­lem, be­cause the scope is al­ready nar­rowed.

Just to be clear, this is by no means an ab­so­lute state­men­t, but an idea pre­sent­ed in or­der to write bet­ter code. One of the things I like the most about Python is that en­cour­ages good prac­tices. There­fore, if I read­ an im­port state­ment like this, un­less there are some very good rea­sons to do so, I will think that line as a code-s­mell [2].

[1] import this

Writing forward-compatible software in Python

Python 3 is the fu­ture of Python. How­ev­er there might be a prob­lem in the ­com­mu­ni­ty if both Python 3 and 2 co­ex­ist. The for­mer one was great and bril­liant, but it is time to start writ­ing soft­ware in the new ver­sion in or­der ­to move to­wards new fea­tures and im­prove­ments.

Let’s start by the be­gin­ning. One of the rea­sons I al­ways pre­ferred Python over the rest of the pro­gram­ming lan­guages is be­cause it is more ad­vanced, mean­ing that in­clud­ed many con­cepts that oth­er lan­guages did not. For ex­am­ple, think of how ear­ly Python adopt­ed ideas like lamb­da func­tion­s, dy­nam­ic typ­ing, ­duck typ­ing, con­text man­ager­s, meta­class­es and so on, while oth­er tech­nolo­gies (­name­ly Java, C++ for ex­am­ple [1]) were still us­ing da­ta struc­tures and call­ing them “ob­ject­s”. Python has al­ways been many steps ahead.

Great news are that this is no over: Python is still im­prov­ing at a fast pace. And that is pre­cise­ly the is­sue with Python 3. As a re­sult of that evo­lu­tion, the new ver­sion of Python must change some of its in­ter­nals in or­der ­to prop­er­ly im­ple­ment new fea­tures, and this is what lead it to be in­com­pat­i­ble with ear­li­er ver­sion­s, which should not be a prob­lem. But it seems it is.

Some de­vel­op­ers do not like the new re­lease, and they are not keen on mi­grat­ing the code base. They ar­gue that Python 3 “is wrong” be­cause it is not back­wards com­pat­i­ble, but my ques­tion here is why are we think­ing back­wards in­stead of for­wards. A pro­gram­ming lan­guage as a mod­el or con­cep­t, must evolve, im­prove, so we should be think­ing on the fu­ture of the lan­guage rather that on it­s ­past. I think they are miss­ing the new ideas, the way Python is chang­ing in­ order to in­cor­po­rate more ef­fi­cient mech­a­nism­s. Per­haps this time, the leap was ­too big.

I think the best for the lan­guage is to adopt its new ver­sion, and do not think of it as a dif­fer­ent one. There­fore, when we say “Python”, it should be un­der­stood that we are talk­ing about just one sin­gle ver­sion.

[1] At the time of this writing just the latest version of Java incorporated lambda expressions, which have been available in Python for many years.

Presentations with reveal.js

Old-­fash­ioned PP­T’s pre­sen­ta­tions are from the 90’s, and let’s face it, we are in the age of the web brows­er. So, the last time I had to gave a talk, I de­cid­ed to use a bet­ter tech­ni­cal sup­port.

Af­ter a quick search for al­ter­na­tives, I found many op­tion­s, in­clud­ing well-­known li­braries, un­til I fi­nal­ly de­cid­ed for re­veal.js.

It is writ­ten in JavaScript with good CSS themes, and it does not re­quire ex­pert knowl­edge on those tech­nolo­gies. In or­der to play the pre­sen­ta­tion, you launch an HTML file from a web brows­er or y­ou can al­so run it with a stat­ic serv­er.


  • Ver­sion con­trol: Giv­en the fact that your pre­sen­ta­tion is made from source code, it is pos­si­ble ­to track changes by us­ing git.
  • A bet­ter cross-­plat­form sup­port: it does not re­ly on a par­tic­u­lar soft­ware in a par­tic­u­lar ver­sion to be present (web browsers are ubiq­ui­tous nowa­days).
  • Com­pat­i­bil­i­ty: WYSI­WYG.
  • Able to host your pre­sen­ta­tion in the cloud and ac­cess it from any­where.

Rea­sons to use it / nice things about it:

  • We are in 2014
  • Sup­ports Mark­down lan­guage

To be clear: I am not say­ing that this is a bet­ter al­ter­na­tive be­cause is new­er of mod­ern, but be­cause of the ad­van­tages list­ed. In oth­er word­s, if we count with de­vel­oped tool­s at our dis­pos­al, it would be a good idea to use them.

Here are some sim­ple and ba­sic ex­am­ples of pre­sen­ta­tions I am work­ing on. (DIS­CLAIMER: they might be in dif­fer­ent lan­guages, and the page is in pro­gress).

Vim commands for improved productivity


I would like to de­scribe my favourite Vim com­mands that I use on a dai­ly ba­sis, in or­der to share some tips that could help you if you are new in this ed­i­tor, or ­to im­prove your ex­pe­ri­ence even if you use it.

  • J : Use­ful when or­ga­niz­ing code, this will join the line be­low to the cur­rent one.
  • ci) (“change in­side ‘)’): Ac­tu­al­ly, the clos­ing brack­et could be changed by any oth­er thing (­like ‘]’, ‘}’, etc.). This will erase ev­ery­thing with­in the brack­ets and set you in in­sert mod­e (the c could al­so be changed for d for ex­am­ple if you just want to delete). Again, this is very use­ful when refac­tor­ing code, if you want to change the pa­ram­e­ters of a func­tion def­i­ni­tion, or what­ev­er is in a block, etc.
  • (s­e­lect some code with vis­ual mode and then) zf : will fold the se­lect­ed code. zd for un­fold­ing.
  • % : alone or along with some oth­er op­er­a­tor, is use­ful for op­er­at­ing with match­ing brack­ets in the code. It will match the clos­ing brack­et of the one you have the cur­sor in.
  • C or D : if you want to change or delete from the cur­rent po­si­tion up to the end of the line, re­spec­tive­ly.
  • t, (or any oth­er char­ac­ter in­stead of com­ma) will point you until that char­ac­ter. The good about this, is that is pos­si­ble to chain it with oth­er com­mand­s, for ex­am­ple: “ct,” will change all the con­tent un­til the next com­ma.
  • < or > will in­dent the code fol­low­ing the “ar­row” di­rec­tion (ac­cord­ing to what is set in shiftwidth).
  • = Au­to­mat­i­cal­ly in­dents code (use­ful when high­light­ing code in vis­ual mod­e).
  • w, e or b will point you to the next wor­d, to the end of the word, or back to the pre­vi­ous word, re­spec­tive­ly. The nice thing about these op­er­a­tors is when they work ­com­bined with oth­er­s, for ex­am­ple:
    • cw will change the next word.
    • db will delete the pre­vi­ous word.
  • { or } for mov­ing up or down through para­graph­s, re­spec­tive­ly.

In ad­di­tion, note that you do not need to know all pos­si­ble com­mand­s, just those that will help you with your nor­mal ac­tiv­i­ties. This means that is could be enough with a smal­l­ ­sub­set of all the fea­tures (the list I wrote is very short in­deed). And this is pre­cise­ly the idea be­hind this post: to show how ­some few com­mands ap­plied in the right con­tex­t, might make you ed­it faster.

All in al­l, Vim is a great ed­i­tor, full of amaz­ing fea­tures. Learn­ing it is ac­tu­al­ly worth it, in the sense that you will get an amaz­ing pro­duc­tiv­i­ty in re­turn (y­ou’ll type and ed­it ­code faster).

Default arguments in Python functions

This post is based on a gist I wrote a while ago, about why is not a good idea to pass de­fault mu­ta­ble ob­jects as pa­ram­e­ter­s in python func­tion def­i­ni­tion­s.

While the gist is ex­plained through an ex­am­ple that us­es list­s, the prin­ci­ple is ap­pli­ca­ble to all sorts of ob­jects (dic­tionar­ies, set­s, etc.).

If you are an ex­pe­ri­enced python de­vel­op­er, you prob­a­bly knew this caveat, n­ev­er­the­less is some­thing in­ter­est­ing to show to new python de­vel­op­er­s, and ­to re­mem­ber even if you have been writ­ing code in Python for years.

Starting a gnome-shell extension

Since I moved from Ubun­tu to Fe­do­ra ear­ly this year, I changed my desk­top en­vi­ron­ment from uni­ty to Gnome Shel­l.

I must say it is a great ex­pe­ri­ence. At the be­gin­ning I was think­ing on what was bet­ter com­pared to uni­ty (be­cause I did not like Uni­ty). Re­gard­ing this ­com­par­i­son I found a more sta­ble and us­able win­dow man­ag­er. I still pre­fer some­thing sim­pler per­hap­s, but it works good and it is nice.

Just out of cu­rios­i­ty, one day I start­ed man­ag­ing some ex­ten­sion­s. Oh, by the way, y­ou will prob­a­bly be in­stalling some ex­ten­sions for Gnome shel­l, some of them are use­ful and some oth­ers make it more us­able. That drove me to the ex­ten­sions de­vel­op­er API, which turned out to be quite sim­ple and in­ter­est­ing.

Hav­ing played a lit­tle bit, I de­cid­ed to code a (very) sim­ple ex­ten­sion that does just one s­in­gle thing. I called it “sim­ple-­name” and it is avail­able at: Sim­ple-­Name-Ex­ten­sion

It re­mem­bers some lit­tle de­tail I was miss­ing from some pre­vi­ous win­dow man­agers that I have used along the years, which is to dis­play the user­name of the cur­rent­ly logged-in us­er.

I must say that, I code it just for the sake of learn­ing and ex­per­i­ment­ing with and API and a bit of JavaScrip­t. In ad­di­tion I found very in­ter­est­ing to see fron­t-end re­lat­ed tech­nolo­gies like JavaScript or CSS used in the desk­top en­vi­ron­ment (not that is some­thing new, but still fun­ny).

To sum up, I want­ed to high­light that is in­ter­est­ing to learn new tech­nolo­gies, even with lit­tle and sim­ple steps like a new API, li­brary, etc. It is not for the tech­nol­o­gy it­self, but for the sake of learn­ing :)

On returning consistent data types

This post is in­spired on an is­sue I once found, while I was us­ing a well-­known li­brary in Python for ­pars­ing YAML files. The prob­lem was that when it was load­ing the con­tent of the file, the re­sult was not co­her­en­t, be­cause some­times it re­turned the con­tent as a python dict, but if the file was emp­ty, the re­turn val­ue was None.

Do you no­tice some­thing odd here?

What if I want to use the re­sult? I can­not do it safe­ly, for ex­am­ple:

content = yaml.load(...)  # with the correct parameters and file name
for tag, values in content.items():
    pass  # process as required...

If con­tent is None, it will raise an At­tribu­teEr­ror say­ing that None has no at­tribute called “item­s” (which is true).

There­fore, the de­vel­op­er should catch the ex­cep­tion or avoid the cor­ner case, ­by do­ing some­thing like the fol­low­ing:

content = yaml.load() or {}

That could be a case of “cod­ing de­fen­sive­ly”, mak­ing sure that the pro­gram will not fail un­der­ ­most con­di­tions (it would al­so re­quire to add an as­sert or to raise an ex­cep­tion per­hap­s, but that is a dif­fer­ent top­ic). I ac­tu­al­ly agree with de­fen­sive pro­gram­ming, but I think it is bet­ter if the li­brary it­self has a more cor­rect be­haviour, re­spect­ing the in­ter­face (that is: if you are go­ing to re­turn a dic­tio­nary, and there is not con­tent, then the log­i­cal as­sump­tion is to ex­pect an emp­ty dic­tio­nary). This must be the de­fault be­haviour, not some­thing to be set by pa­ram­e­ter­s.

This could be thought as an in­stance of a more gen­er­al prob­lem that oc­curs when some func­tion is in­tend­ed to re­turn “X or Y”. In my opin­ion, if X and Y do not share the same in­ter­face, there is a po­ten­tial bug (in the Ob­jec­t-Ori­ent­ed par­a­digm we would say that there is no poly­mor­phis­m, or maybe that the “con­trac­t” is not be­ing re­spect­ed).

This is an ex­am­ple that I want­ed to high­light, be­cause it might help you to write clean­er code.