[Python-Dev] python-dev Summary for 2003-02-01 through 2003-02-15

[Samuele Pedroni]

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... .