I think the real code sample I located is pretty typical. Look at that other post.
Let me see if I understand your workflow:
Well... "My workflow" is "Get a bunch of code that was written years before I was at my company, and enhance it or fix it without breaking everything else." I don't think my workflow is uncommon. :-)
But in terms of dataflow, your characterization is accurate.
1. upstream: you build up a nested data structure, adding elements as needed
2. midstream: you treat the nested data structure as "a bunch of stuff"
3. downstream: you pull the nested data structure apart
list.append(myset) # fine, sets can go into lists
set.add(myset) # fails, because sets aren't hashable
Yes. Obviously there are constraints and differences between different collections. But the example I found is both commonplace and allows us not to worry about more of that.
If you have a collection of distinct strings, a bunch of different collections can hold them. `for thing in collection` works for various data types. Collections of numbers are similar. `sum(the_numbers)` is happy with anything iterable, for example.
(don't you have an IDE with a refactor command for that?^1 )
^1 I don't, so I'm not entirely unsympathetic to this argument.
I really don't!
It would be cool to have some keystrokes that identified everything that might be affected is I changed 'foo' from a list to a set... but it seems subtle. Everywhere foo might occur in call chains through every renaming as a formal parameter or otherwise.
My hunch is this is simpler than solving the halting problem, but it doesn't feel easy. Maybe tools do it. Even getting CTAGS integrated with vim would help somewhat.