Well - quite a bad example to show my doubts, I should have sticked to the more "quiet" left_pad in the first time :)

This demonstrates that there's always something to learn, particularly where you don't suspect it. I wrote the detaint function to "free" some directory and file names after verifying they're real dir and files with "-X" tests, so I was confident they were right and I felt comfortable about them. And I erroneously concentrated on the wrong problem - or better, I had nothing better to do than "Meditate" at that moment.

But what I'll keep in mind is that whenever I strive for generality and reusability letting myself lose time, things could (and will hopefully be) used in contexts quite different from the ones I've developed them. So wondering how to make a detaint function the most general one is very similar to a Bad Thing, because encourages potentially bad coding practices (like not verifying your data).

Once you figure out what you want, clearly document it.

I hope this will become natural for me; I really admire the fact that this thing has become such a habit for a recognised Guru to forget to say "before you code", which I read nonetheless. I'm a naive programmer, and I tend to document things after I've done them, but I understand that writing documentation first will help me fixating ideas and stick to one solution instead of refactoring brainlessly.

Just to answer myself a bit regarding the in-place modification avoiding copying large chunks of data, I remembered an old motto: A premature optimisation is a Bad Thing. For what old can mean in CS :)