A commmon pattern I've noticed in my Python code follows this simple structure:

value = get_val_from_thing()
value = mutate_that_val(value) 

I find myself first grabbing some specific value(s) from some data structure and then I set the reference to that value to a mutated version of the previous value by passing the value into some function.

Here's a concrete example I found in some code:

paths = response[0]["job.ResultPaths"]
paths = paths.split(",")
paths = list(filter(None, paths)

So my questions are: Is there a name for this pattern? Is it good/bad practice?

And also, would it make more sense to condense this into something like:

value = mutate_that_val(get_val_from_thing())
  • "would it make more sense to condense this into something like:" only if the result get_val_from_thing is very obvious from its name, and wouldn't benefit from being assigned to a descriptively named variable
    – Alexander
    Commented Aug 12, 2019 at 22:51
  • 1
    The problem with condensing code like this is that it's more a painful debugging experience, especially when stepping through it. I would favor code clarity at the expense of more lines of code.
    – aybe
    Commented Aug 13, 2019 at 4:39
  • What do you find remarkable about this? That the same variable receives values of different types? Commented Aug 13, 2019 at 6:17
  • 1
    Possible duplicate of Should I reuse variables? Commented Aug 13, 2019 at 7:20
  • Off the top of my head, there are two cases where code is often written in this way. First, this is not unlike how you'd work with immutable values; you get some value, and then produce from it another copy that's slightly changed. In that case both the source and the result are of the same type. The other situation is like in the example you show - you have to go through a bunch of intermediate values before you get to what you want. I find it helpful to give the final result a distinct name and refer to it only by that name from then on. Commented Aug 13, 2019 at 10:13

2 Answers 2


We certainly do have names for this.

You are combining two things: Variable Reuse and Intermediate Variables.

Reusing a variable is sometimes questionable but, well, that's why we call them variables. If computers had unlimited memory and humans had an unlimited vocabulary to draw on when naming them maybe we could rid ourselves of the uncertainty of one name (and memory address) meaning different things at different times. But we don't, so here we are.

Intermediate Values are used to break up Functional Composition. The style does nothing to change the steps the computer takes. In fact it has a refactoring. It gives you a place to put descriptive names for the results of each function call. It's not exclusively a Python thing.

Intermediate values don't have to be reused. They can be immutable consts, provided you have the memory and the vocabulary. But sometimes it is actually more readable to stick with one name for the thing you're transforming. When you do this, don't leave half transformed copies of it laying around. It's confusing as all hell if your one name means two things at the same time.

would it make more sense to condense this into something like

value = mutate_that_val(get_val_from_thing())

The reason this sucks is that the only descriptive name you had here, "paths", has been squeezed right out. I mean: get_val_from_thing()? Come on.

The main advantage of the intermediate variable style is that it gives you more places to put descriptive names. The main disadvantage is that to use it effectively you must come up with descriptive names.

You're weaseling around that disadvantage by coming up with one descriptive name and reusing it. Which is fine. So long as you make which form the data is in at each step obvious. A name like: get_val_from_thing() doesn't do that. A name like: paths.split(",") does.

  • get_val_from_thing() is a genericalised name. It could be get_sender_from_email() or many other examples, which does describe the operation.
    – Baldrickk
    Commented Sep 9, 2019 at 14:32

No there is no name for it and it is hardly a pattern. It is breaking up logic into smaller steps which is ultimately what we always do as programmers, regardless the context.

  • 2
    Actually, mutating variable bindings, and specifically, mutating variable bindings to values of different types is not universally, but widely considered an anti-pattern or at least a code smell. Commented Aug 13, 2019 at 7:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.