Steve Jorgensen wrote:
had not thought of that. That actually does work. :) I would say that means there is no need for a new feature, but would it make sense for this idiom to be documented in a PEP or some other easily discoverable place?
Sorry. I forgot to quote for context. Random832 wrote:
On Mon, Oct 21, 2019, at 22:00, Steve Jorgensen wrote: I think some idea like this might be worth proposing. the first idea that comes to my mind is to allow the name of a decorator to be an fstring using @'...' or @"..." syntax. If, for example, you have method_type = 'class', then you could decorate a method using @'{method_type}method'. I'm not sure if this is a very good example (there's no "normalmethod" to return no decorator, and staticmethod typically needs a different function signature with no self/cls)... and for any nontrivial case I can imagine, it's taken care of by the ability to call a function. For example, for your case you can simply def m(method_type): if method_type == 'static': return staticmethod elif method_type == 'class': return classmethod elif method_type == 'normal': return lambda f: f else: # do what here? are you extending with additional "foomethod" decorators? and then do @m(method_type). Sorry, when posting this, I hadn't seen Yonatan Zunger's original post yet, only
On Mon, Oct 21, 2019, at 22:30, Random832 wrote: this reply. I do see the utility for that suggestion, but not really for this one allowing a decorator to be a string that will be evaluated. [and if you really want yours literally, you could simply do @eval(f'{method_type}method'), or something else in case method_type may contain characters that are not part of an identifier.