From: "Brett Cannon" <bac@OCF.Berkeley.EDU> > ============================= > `Extended Function syntax`__ > ============================= ... > A variant on all of this that was proposed was:: > > def fxn(args) as fun1, fun2, ..., funX: > ...code... > > or:: > ... > The two proposed syntaxes above were suggested to be made very general so > that you could do something like:: > > def fxn(args) as function: > ...code... > > And since this was all about how make using property() easier, > property-specific suggestions included: > > class klass(object): > property prup: > ...code... > > or:: > > class klass(object): > def prup as property: > ...code... > > The problem with the former is that it requires turning "property" into a > keyword. > > None of these are PEPs yet nor have had BDFL pronouncement. it is (maybe) worth to remember that the syntaxes: def fun(args) as staticmethod: ... def Interface(J,K) as interface: ... cannot really be supported together (unless to go for a super kludgy & ambiguous solution), because the former requires formal parameters and the latter takes a tuple of expressions to be computed at definition time. > > =========== > `thunks`__ > =========== > __ http://mail.python.org/pipermail/python-dev/2003-February/032828.html > > Splinter threads: > - `Extended Function syntax > <http://mail.python.org/pipermail/python-dev/2003-February/032694.html>`__ > - `exec/with thunk-handling proposal > <http://mail.python.org/pipermail/python-dev/2003-February/032800.html>`__ > > Thanks to Samuele Pedroni for providing me a technical summary that I was > able to use to help write this summary. > > The concept of adding thunks to Python came up through the extended > function syntax thread (in case you don't know what a thunk is, you can > think of it as a chunk of code that is compiled and ready to use but is > not executed until a later time). Some suggested syntaxes were:: > > lvalue = thunk(args): > ...code... > > or:: > > do lvalue = thunk(args): > ...code... > thunk(args) above is probably more precisely thunk_consumer_maker(args) (I think I called it a "behavior"), the thunk truly would be a reification of the ...code... suite, i.e. an object for ...code... .
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