Vim is an excellent editor, and mastering it leads to more productivity. Even though is very extensible and allows to be configured by many plug-ins I rather keep it as simple as possible, trying not to use many plug-ins (neither packagers like Vundle, etc.).

However, I do make use of an extension that checks Python files for errors, PEP8, among other things: flake8. Because I do not use plug-in platforms for Vim, I install just this one manually, by making the command flake8 available system-wide 1.

Then the installation is as simple as downloading the project and coying the files into the ~/.vim/ft­plug­in/python directory. Make sure you have the following line added on your ~/.vim­rc:

filetype plugin indent on

The features I use are mainly the syntax and PEP-8 compliance checkers. It can also warn you about unused imports, and cyclomatic complexity.

It is useful because things like PEP-8 compliance help to have a good code quality, and therefore a more readable and maintainable code base, specially on large projects with lots of files and modules.

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

1

An­oth­er op­tion would be to in­stall it on your vir­tu­al en­vi­ron­men­t, but then you have to make sure to in­stall it once per projec­t. It is ac­tu­al­ly bet­ter, be­cause you are not us­ing the glob­al sys­tem en­vi­ron­men­t, but for pack­ages like this, it should not be an is­sue, it’s your choice.

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­tions 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 an­oth­er old­er ac­count I have

Fedora 21 workstation seems to come with a lot of virtualization features and most of the libvirt libraries installed. I only had to add the KVM vir­tu­al-­man­ag­er which is the KVM application I am more familiar with. However, the new version of the libvirt* libraries have networking features that are great for the data centre environment, but maybe not the best option for a particular workstation, so I added the following packages in order to set up an easier network configuration for my local virtual machines.

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.

It is well-known among Python developers (or at least, it should be), that is a bad idea to import everything from a module, for example by doing from <module> import *.

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 iden­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 means 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 de­f­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

im­port this

2

http­s://c2.­com/cgi/wik­i?­CodeSmell

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 its past. I think they are miss­ing the new ideas, the way Python is chang­ing in or­der 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 writ­ing just the lat­est ver­sion of Ja­va in­cor­po­rat­ed lamb­da ex­pres­sion­s, which have been avail­able in Python for many years.

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 you can al­so run it with a stat­ic serv­er.

Ad­van­tages:

• 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 tools 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).

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­ters 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, nev­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.

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, you 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 sin­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 :)

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:

If content is None, it will raise an AttributeError saying that None has no attribute called “items” (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 “coding defensively”, making sure that the program will not fail under most conditions (it would also require to add an assert or to raise an exception perhaps, but that is a different topic). I actually agree with defensive programming, but I think it is better if the library itself has a more correct behaviour, respecting the interface (that is: if you are going to return a dictionary, and there is not content, then the logical assumption is to expect an empty dictionary). This must be the default behaviour, not something to be set by parameters.

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.