There is a wonderful feature in Python import statement to make an alias for an imported object (
import foo.bar.baz as fbb). It allows to avoid name conflicts and improve code readability if necessary. And of course, using it you can easily turn your perfect code into a completely unreadable mess. Recently I’ve seen this several times. I’ve met some strange abbreviations and confusing aliases.
Let me show you an example of a problem with abbreviations. Here is a good example. It’s not from real code, but it looks very similar.
from facebook import utils as fbu
from twitter import units as tu
Ok. We resolve the name conflict. But what does
tu mean? If I see such names in code, I have to make extra efforts to understand what an author means. It is much better if there is something like this instead of ugly abbreviations:
from facebook import utils as facebook_utils
from twitter import units as twitter_utils
Now the code is much cleaner. Sure variable names are longer. But who spares bytes nowadays? I think I would use this formula even if there was only one import from utils library, just to improve readability.
It looks obvious to me. However, it is not so easy to prove that readability is important. Usually, other developers answer that you can always check the import section to understand their meanings. Of course, I can. There are no problems in any good IDE: point to an interesting position in code, do to a declaration, read it and go back.
But developers read code mostly on Github or similar systems. We usually read small diff, that may not include an import section. And you have to “unfold” that diff to find the imports. And there is no code navigation. So let’s save the time of readers using meaningful aliases in imports.
What do you think? Is it worth rejecting PRs?
Got a question? Hit me on Twitter: avkorablev