Hello Ronald,
> I'm in favor of @decorators. It's easy to notice them when the are
> present and they are clearly special. The '[decorator] def ...' and
Why are they special? Why should they be more important than any other
part of the function definition?
> 'decorate(decorator) def ...' are very magic, and are IMHO unfriendly
> to newbies (you must metion them in any introduction to python, because
> otherwise users would complety mis the signicance of the decorations).
[...]
> @objc.signature("v@:@i")
> def saveSheetDidDismiss_returnCode_contextInfo_(self, sheet,
> returnCode, contextInfo):
> pass
>
> The argument to objc.signature is fairly magic and I do try to abstract
> it away (such as with the introduction of objc.accessor), but that's
> not always possible. If decorators were not allowed to have arguments
> I'd have to introduce temporary functions that wouldn't help in
> readability.
Is special syntax in the language really required in this case,
considering you're already doing something "fairly magic" anyways?
What is objc.signature() doing?
> The generic example PJE is introducing in PEAK also seem a good usecase
> for decorators with arguments.
Any pointers?
I'd really like to "see the light" of complex decorators, as oposed
to KISS, and use the current language features to implement that.
--
Gustavo Niemeyer
http://niemeyer.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4