"Does it… work?" is not the standard by which good Python code is measured. Django went through this process years ago. It's convenient to be able to call `from myapp.models import *` and have an `Articles` model magically added to your module even though you never defined. They realized years ago that writing clever code for the sake of being clever was a bad idea. How are you going to get someone else to be able to maintain it? Not only do they have to know the logic of what you're doing, they have to know how you hacked things together.

Line 17 of PEP-20 sums up my thoughts on this code as more than an intellectual exercise.

> If the implementation is hard to explain, it's a bad idea.

Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job?

> If the implementation is hard to explain, it's a bad idea.

I don't think this principle is universal in software, and I don't think you need to embrace it as a prerequisite for writing or distributing Python code. My personal preference would be for a statement more like this, "If the implementation is more complicated than it needs to be to do what you want, it's probably a bad idea."

> Regarding using Python as a replacement for shell scripting: if you have to rewire the language to do what you want, why are you using a different tool for the job?

Well that's easy to answer. It's cleaner and more readable than bash, has some nice features that shell scripts lack, can be used to call into python libraries, allows a single unified codebase if you're already writing python code . . . I could go on.