[Python-Dev] Extended Function syntax

[Andrew McGregor]

--==========1899669384==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



--On Thursday, January 30, 2003 21:02:23 -0500 Guido van Rossum=20
<guido@python.org> wrote:

>> > How about
>> >
>> >   foo =3D property:
>> >       ...
>>
>> That looks quite nice to me, if it can be parsed...

I think it's quite cool too.

> That's the first bit of positive feedback I got on this proposal all
> day. :-)
>
> Fortunately the second bit came soon (although Raymond left in an
> attribution to Greg Ewing that seemed to imply it was his idea :-).
>
> And as another opening remark, I didn't mean this to replace the
> [prop, prop, ...] syntax on function/method defs -- that seems a
> useful addition in its own right.  I'm not so sure that it also
> applies to classes -- there we already have metaclasses.

But

class Foo(FooBase) is synchronised:
    pass

or

class Foo(FooBase) [synchronised]:
    pass

as you prefer make nice syntax for a metabase application.

> The form above can be parsed easily, if we say that "colon followed by
> suite" is allowed only at the end of a simple assignment or expression
> statement.

Can we allow it as an argument to a function?

Something like:
do_stuff(a=3De:
             S
         # Hmm, this comma is odd...  maybe it needs to be implicit
         ,b=3De:
              S1
         )


> Note that 'property' and 'synchronized' used as examples are not new
> keywords!  They are just built-in objects that have the desired
> semantics and know about thunks.

Which is neat.

> BTW, I'd be interested in entertaining different syntactic proposals
> that would make it less likely that a typo would accidentally turn
> something into a thunk call.  It worries me that leaving out 'def' in
> a simple function definition could turn it into code that gives a
> TypeError when executed rather than a SyntaxError.  (Forgetting 'def'
> is a mistake I frequently make.)
>
>
> Samuele rightly questioned the semantics of the thunk with regard to
> namespaces though.  In the example of a locking section:
>
>   synchronized(aLock):
>     BLOCK
>
> you'd want the scope of BLOCK to be the same as that of the
> surrounding code, just as with an if or try statement.
>
> Note that synchronized() must be a function of one argument that
> *returns a function*.  Something like this:
>
>   def synchronized(lock):
>     def f(thunk):
>       lock.acquire()
>       try:
>         thunk()
>       finally:
>         lock.release()
>     return f
>
> On the other hand, when using the same syntax to define a property:
>
>   foo =3D property:
>     "docs"
>     def get(self):
>       return self.__foo
>     def set(self, value):
>       self.__foo =3D value
>
> we would like the thunk to be executed in a new scope.
>
> In this case, the property constructor must (1) detect that it is
> being called with a thunk argument, and (2) in that case, *call* the
> thunk (so the def statements inside the thunk are executed) and
> somehow extract them from the thunk's namespace.

How about using the containing namespace if we return a thunk rather than a =

function (using two arguments so we can pass in the body):

  def synchronized(block, lock):
    f =3D thunk:
      lock.acquire()
      try:
        block()
      finally:
        lock.release()
    return f

or even:

  def synchronized(block, lock):
    return thunk:
      lock.acquire()
      try:
        block()
      finally:
        lock.release()

This would allow:

def defproperty(block):
    block()
    return property(get, set, del, block.__doc__)

so we can make the new namespace that the property exists in be our locals.

Or am I making no sense at all?

Andrew

--==========1899669384==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+OpJ4HamGxvX4LwIRAmQPAJsG1Hwz/yy39cHBvSYN+GNbE6PwQQCfaQA0
6jnODrobgqm4xLPVpb9YZQE=
=dWNM
-----END PGP SIGNATURE-----

--==========1899669384==========--