Python – Using “intermediate variables” to abbreviate long dict entries

coding-stylepythonvariables

Sometimes I come across the situation that I have some data in a nested dict with rather long key-names (sometimes unavoidable for one reason or another).

some_dict = {'not_too_short_key_one': {'second_lvl_key_one': 23,
                                       'one_more_second_lvl_key': 5},
             'not_too_short_key_two': {'second_lvl_key_two': 123,
                                       'one_more_second_lvl_key': 321}}

At times I then have to pass some elements of the dict into some functions more than once:

# option 1

do_something(some_dict['not_too_short_key_one']['second_lvl_key_one'])

do_something_more(some_dict['not_too_short_key_one']['second_lvl_key_one'],
                  some_dict['not_too_short_key_one']['second_lvl_key_two'])

do_yet_another_thing(some_dict['not_too_short_key_one']['second_lvl_key_one',
                     some_dict['not_too_short_key_one']['second_lvl_key_two',
                     some_dict['not_too_short_key_two']['second_lvl_key_one'])

do_yet_another_thing(some_dict['not_too_short_key_one']['second_lvl_key_one',
                     some_dict['not_too_short_key_one']['second_lvl_key_two',
                     some_dict['not_too_short_key_two']['second_lvl_key_one'])

I wonder if introducing variables with the sole purpose to abbreviate dict entries makes sense in these situations. Would the following be encouraged? One the one hand it makes individual function calls somewhat less verbose and may significantly reduce overall code-size. On the other hand, each variable that gets introduced might change and thus makes it harder for another person to understand how the program works. Also it adds another level of indirection for a reader.

# option 2

item_1 = some_dict['not_too_short_key_one']['second_lvl_key_one']
item_2 = some_dict['not_too_short_key_one']['second_lvl_key_two']
item_3 = some_dict['not_too_short_key_two']['second_lvl_key_two']

do_something(item_1)
do_something_more(item_1, item_2)
do_yet_another_thing(item_1, item_2, item_3)
do_yet_another_thing(item_1, item_2, item_3)

Is there some sort of consensus on how to deal with this issue (e.g. prefer option 1 or option 2) or maybe some sort of naming convention for "abbreviation variables" that is generally agreed upon?

Best Answer

This is absolutely a good thing to do. Introducing intermediate variables with meaningful names simultaneously reduces reading time and adds implicit documentation.

If you're worried about the values inadvertently changing, you can make the new vars final (well, not in Python, but in principle).

In practice the advantages are even clearer than in your example because it's so abstract. Exchanging something like

configurator['hkey_local_machine'][0]['interfaces']['IP4']

with

my_ip

is a no-brainer in my view.

Related Solutions

Java – How to write useful Java programs without using mutable variables

Is it possible to implement such an example in Java without using destructive updates? Yes. However, as @Thiton and the article itself mentioned, it will be ugly (depending on one's taste). One way is using recursion; here's a Haskell example that does something similar:

unfoldr      :: (b -> Maybe (a, b)) -> b -> [a]
unfoldr f b  =
  case f b of
   Just (a,new_b) -> a : unfoldr f new_b
   Nothing        -> []

Note 1) the lack of mutation, 2) the use of recursion, and 3) the lack of loops. The last point is very important -- functional languages don't need looping constructs built into the language, since recursion can be used for most (all?) cases where loops are used in Java. Here's a well-known series of papers showing how incredibly expressive function calls can be.

I found the article unsatisfying and would like to make a couple of additional points:

That article is a very poor and confusing explanation of functional programming and its benefits. I would strongly recommend other sources for learning about functional programming.

The most confusing part about the article is that it doesn't mention that there are two uses for assignment statements in Java (and most other mainstream languages):

binding a value to a name: final int MAX_SIZE = 100;
destructive update: int a = 3; a += 1; a++;

Functional programming eschews the second, but embraces the first (examples: let-expressions, function parameters, top-level defineitions). This is a very important point to grasp, because otherwise the article just seems silly and might leave you wondering, what are take, squares-of, and integers if not variables?

In addition, the example is meaningless. It doesn't show the implementations of take, squares-of, or integers. For all we know, they are implemented using mutable variables. As @Martin said, you can trivially write this example in Java.

Once again, I would recommend avoiding this article and others like it if you really want to learn about functional programming. It seems to be written more with the goal of shocking and offending rather than teaching concepts and fundamentals. Instead, why not check out one of my all-time favorite papers, by John Hughes. Hughes tries to tackle some of the same issues that the article covered (although Hughes doesn't talk about concurrency/parallelization); here's a teaser:

This paper is an attempt to demonstrate to the larger community of (nonfunctional) programmers the signiﬁcance of functional programming, and also to help functional programmers exploit its advantages to the full by making it clear what those advantages are.

[...]

We shall argue in the remainder of this paper that functional languages provide two new, very important kinds of glue. We shall give some examples of programs that can be modularized in new ways and can thereby be simpliﬁed. This is the key to functional programming’s power — it allows improved modularization. It is also the goal for which functional programmers must strive — smaller and simpler and more general modules, glued together with the new glues we shall describe.

Java – Elegant Ways to Avoid Hard Coding CSV File Format

Regardless of language, if you don't want to hard code the values, then one will need some sort of meta data that describes how the data will be mapped, formatted, and output.

In this example, it could be called a mapper or formatter.

Map/format files (XML, JSON, or simliar) would describe how the data would be formatted and written. Your application would read in the map/format file and use it to create the output.

Then your application could format the CSV anyway you see fit, without a programming change. One could also extend this to flat or fixed formats and XML as well. Then your code is generic as it uses the mapping meta data to create the CSV file.

For the CSV case, at a high level one would need to describe:

Name and Order of fields
Delimiter (Sometimes comma is not used)
Whether or not to include a header
Whether or not to include quotes around the data

Just as a side note, there is a time difference to develop the two applications. Hardcoded field values are much faster to develop, although as you have pointed out less elegant. But if you need to get something done quickly, the aproach is OK.

Developing something more generic would take more time up front, but if your producing a lot of CSV formatted files of different format, in the long run one would get ROI on it.

With this approach, one can also write some sort of nice "GUI" for business analysts to use to create the map files so developers will be less involved in the overall process.

Best Answer

Related Solutions

Java – How to write useful Java programs without using mutable variables

Java – Elegant Ways to Avoid Hard Coding CSV File Format

Related Topic