Re: Call for defense of @decorators
Hi, Having read the PEP, most of the py-dev discussion and the EuroPython slides just now (sorry, maybe I'm late by a couple of months :-), the call for defense is a tough call for me. I am -0. There is no new functionality and actually my impression is that there is potential for code readability to get hurt. The argumentation for the change in the PEP seems to be weak. It is explicitly stated that successive @decos are equivalent to chained function calls without the temp vars at definition time. This is indeed a key point. No new functionality is actually added (or a good amount of typed characters saved for that matter). The staticmethod() readability problem is a code readability problem, and as such it can simply be addressed the "classic" way via comments. (BTW, has anyone suggested changing the @deco syntax to #deco? :-) It works for me <0.5 wink>. I do not necessarily perceive the foo = staticmethod(foo) transformation statements as evil too. They are explicit, normal def-time function calls, and we certainly don't need a new way for the job. We might introduce one indeed (I saw the syntax becoming a fact of life already), but we don't really need it to get the job done. IOW, everything the @decos can bring will remain doable the obvious way via function calls. And that's good enough. As for the arguments about future code tools knowing better about the annotated functions / classes via the @decos at definition time, well, it's common practice really (cf. #pragma and all sorts of special comments for compile-time processing) which does not involve new syntax. I perceive the extravaganza in doing one or the other as comparable. That said, looking at what's being done here, and all things being equal, there is certainly some merit in the idea of declaring the def-time caller list of a function before the function itself, but I personally fail to foresee its goodness for Python on most counts. These chained @decos look like a call stack crash dump to me anyway :-) I will happily embrace genexps and multi-line imports though. Thanks! Cheers, Vladimir
participants (1)
-
Vladimir.Marangozov@t-online.de