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