> You're conflating decorator syntax, which I'm not discussing, and decorator functionality, which I am discussing. Guilty as charged. I admit I thought you w

> You're conflating decorator syntax, which I'm not discussing, and decorator functionality, which I am discussing. Guilty as charged. I admit I thought you were talking about decorator syntax. Because decorator-the-technique makes even less sense as an alternative to macros. Decoration is a technique of higher order programming (taking functions as arguments and/or returning them). The fact that you can use it at "compile time" (whatever that means in Python) is a property of the dynamic nature of the language. Yes, that stuff is powerful. But Scheme has all that, and its designers still saw the need to add macros, mostly to do the things that you can't do by executing higher order functions at "compile time". Macros are not essentially about doing stuff at compile time; they're about messing with the very syntax of the language. My point is not just that decorators and macros aren't the same thing; it's that macros are meant explicitly to do what decorators can't. I guess most Python programmers don't miss macros simply because they've never seen the need for them in first place, not because Python has any replacement. The closest alternative that Python has to macros would be eval. In my opinion, what ultimately allows most Python programmers who have been exposed to macros to almost never miss them is the syntactic sugar that the Python authors keep (judiciously) adding every release.