On Mar 31, 2004, at 6:43 PM, Neil Schemenauer wrote: > On Wed, Mar 31, 2004 at 03:04:18PM -0500, Bob Ippolito wrote: >> On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote: >>> Please don't add any decorator syntax to Python, at least not yet. >>> All >>> of the proposals I have seen so far are, to be blunt, and in my >>> opinion >>> of course, ugly and are getting uglier as the discussion ensues. > > I agree with Michel. The decorator syntax being discussed looks > ugly. I think it would be okay if the set of valid decorations were > limited to 'classmethod', 'staticmethod' and maybe a few others. > Allowing more general expressions seems to asking for abuse. > >> Decorators solve a *huge* problem with the current syntax: >> >> def >> someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(takes, >> some, args, here): >> pass >> someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_ = >> objc.selector(someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLon >> ge >> r_, signature='some type signature') > > I would be happer if there was an easier way for you to do what you > want _without_ introducing new syntax to that language. For > example, what if '_' was bound to the last defined function? You > could then do something like this: > > def someObjectiveCSelector_itsReallyLong_(takes, some, args, here): > pass > objc.selector(_, signature='some type signature') > > That looks pretty nice and is even shorter to type than the proposed > syntax. No, that is not correct.. it must rebind the name... it doesn't mutate the function, it returns a selector descriptor. It's also easy to lose once you have functions that do things other than pass. It really ought to be in close proximity to the def statement, if it's not just an extension to the def syntax. -bob
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