You know, my first reaction was the same as yours. But now I'm thinking "nifty hack" now that I've taken my Pythonista hat off.

Exploring stuff like that is what hacking is all about. I'd strangle someone who wrote a library like that for my project (and checked it in), but there's nothing wrong with experimenting now and again.

Correction: Nifty unnecessary hack. Why not just write a function which returns another function that performs the SQL statement? That is almost but not quite exactly what the decorators do and it would accomplish exactly the same goal without clobbering python syntax. An even better solution would just be a function that executes an arbitrary SQL query. That also has the benefit that it can be easily wrapped and easily debugged unlike the current mess.

examples:

create_sql_function(query): return a function that executes query.

execute_sql(query): execute a query.

Usage:

foo = create_sql_function('SELECT a, b FROM bar;') zzz(self, c, d): execute_sql('INSERT INTO ...')

These were my thoughts, too. Using functions instead of decorators would have many more benefits. I guess they could argue that some of the runtime performance moves to instantiation in the decorator approach.

Still, warn the new coders against it, but don't stone the guy. Let people explore. I'm probably one of the few people who didn't want decorators added at all (I think they're ugly and feel less pythonic than decorating after declaration), but I like seeing people experiment.