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 very obvious from its name, and wouldn't benefit from being assigned to a descriptively named variable