Sorry, this seems like a classical example of "When all you have is a hammer, everything looks like a nail. Then, when you learn of a screwdriver, you suddenly see half of these nails as screws, completely ignoring there are other tools besides those two."

In fact, enumerate is _not_ the good choice in most of those cases, as the comments show. One should use zip, another should use ordinary iteration because the index isn't needed at all, and yet another should probably stay as it is, since that way it's more obvious that we're transforming each item in place. [When LHS is consts[i] and right is const, it's not easy to see they refer to the same place.]

Even the fourth I would argue is more readable in the current form, for a similar reason: when you base the decision on words[i], and the decision is to del words[i:], it's obvious you delete "it and everything after". Not so much in the "refactored" code.

Please don't do such things. One of Python's great strengths, especially in stdlib, is code stability. The only reason we're able to get anything done is that we have (or at least used to have) a great policy referred to in https://bugs.python.org/issue31417#msg301879, so we don't lose ourselves in enormous bikeshedding about how to best use the enormous expressivity of Python to write the code that works perfectly fine in some slightly different way.