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 highlight and gather the reasons why this is a bad practice, in order to collectively identify many undesired effects. However, without losing pragmatism, in case there are some odd reasons why this might be acceptable, I will also mention them, if any. Let's see where we get.

Python 3 is the future of Python. However there might be a problem in the community if both Python 3 and 2 coexist. The former one was great and brilliant, but it is time to start writing software in the new version in order to move towards new features and improvements.

Let's start by the beginning. One of the reasons I always preferred Python over the rest of the programming languages is because it is more advanced, meaning that included many concepts that other languages did not. For example, think of how early Python adopted ideas like lambda functions, dynamic typing, duck typing, context managers, metaclasses and so on, while other technologies (namely Java, C++ for example¹) were still using data structures and calling them "objects". Python has always been many steps ahead.

Old-fashioned PPT's presentations are from the 90's, and let's face it, we are in the age of the web browser. So, the last time I had to gave a talk, I decided to use a better technical support.

After a quick search for alternatives, I found many options, including well-known libraries, until I finally decided for reveal.js.

It is written in JavaScript with good CSS themes, and it does not require expert knowledge on those technologies. In order to play the presentation, you launch an HTML file from a web browser or you can also run it with a static server.

---

title: Introduction

I would like to describe my favourite Vim commands that I use on a daily basis, in order to share some tips that could help you if you are new in this editor, or to improve your experience even if you use it.

• J : Useful when organizing code, this will join the line below to the current one.
• ci) ("change inside ')'): Actually, the closing bracket could be changed by any other thing (like ']', '}', etc.). This will erase everything within the brackets and set you in insert mode (the c could also be changed for d for example if you just want to delete). Again, this is very useful when refactoring code, if you want to change the parameters of a function definition, or whatever is in a block, etc.
• (select some code with visual mode and then) zf : will fold the selected code. zd for unfolding.
• % : alone or along with some other operator, is useful for operating with matching brackets in the code. It will match the closing bracket of the one you have the cursor in.
• C or D : if you want to change or delete from the current position up to the end of the line, respectively.
• t, (or any other character instead of comma) will point you until that character. The good about this, is that is possible to chain it with other commands, for example: "ct," will change all the content until the next comma.
• < or > will indent the code following the "arrow" direction (according to what is set in shiftwidth).
• = Automatically indents code (useful when highlighting code in visual mode).
• w, e or b will point you to the next word, to the end of the word, or back to the previous word, respectively. The nice thing about these operators is when they work combined with others, for example:
  • cw will change the next word.
  • db will delete the previous word.
• { or } for moving up or down through paragraphs, respectively.

In addition, note that you do not need to know all possible commands, just those that will help you with your normal activities. This means that is could be enough with a small subset of all the features (the list I wrote is very short indeed). And this is precisely the idea behind this post: to show how some few commands applied in the right context, might make you edit faster.

This post is based on a gist I wrote a while ago, about why is not a good idea to pass default mutable objects as parameters in python function definitions.

While the gist is explained through an example that uses lists, the principle is applicable to all sorts of objects (dictionaries, sets, etc.).

{{ gist(owner=“rmariano” id=“7593536” filename=“function_parameters.md” )}}

If you are an experienced python developer, you probably knew this caveat, nevertheless is something interesting to show to new python developers, and to remember even if you have been writing code in Python for years.

Since I moved from Ubuntu to Fedora early this year, I changed my desktop environment from unity to Gnome Shell.

I must say it is a great experience. At the beginning I was thinking on what was better compared to unity (because I did not like Unity). Regarding this comparison I found a more stable and usable window manager. I still prefer something simpler perhaps, but it works good and it is nice.

This post is inspired on an issue I once found, while I was using a well-known library in Python for parsing YAML files. The problem was that when it was loading the content of the file, the result was not coherent, because sometimes it returned the content as a python dict, but if the file was empty, the return value was None.

Do you notice something odd here?

What if I want to use the result? I cannot do it safely, for example: