On Wed, 29 Jan 2003 23:49:05 -0500, guido@python.org (Guido van Rossum) wrote:

(2 or it could be compiled into a "thunk" which is somehow passed to whatever is called to implement the xdef (like a function body).

Variant (2) gives much more freedom; it would allow us to create functions that can be called later, or it could be executed on the spot to yield its dictionary.

(edit)

I think a thunk should be a callable; upon execution it would return its dict of locals.

Maybe if a thunk contains a 'return' statement it could return the return value instead.

Maybe someone can find a use for a thunk containing 'yield', 'break' or 'continue'.

Maybe all control flow in the thunk should raise an exception that the xdef can catch to decide what happens. Hm, if it did 'yield' you'd like to be able to call next() on it. So maybe there should be different types of thinks that one can distinguish.

(edit)

One think I'd like to do with extensible syntax like this (and for which xdef is a poor name) would be to define a "lock" statement, like Java's "synchronized" block.

Maybe it could be written like this; I made the name after xdef optional:

xdef (mylock) [synchronized]: ...block...

which would mean:

mylock.acquire() try: ...block... finally: mylock.release()

It would be nice if control flow statements (return, break, continue) inside the block would somehow properly transfer control out of the block through the finally block, so that you could write things like

def foo(): for i in sequence: xdef (mylock) [synchronized]: if ...condition...: continue ...more code... if ...condition...: break ...yet more code... if ...condition...: return 42

Wow. I started thinking about this last night, and already there have been many good suggestions.

I make no claims of what follows to be Pythonic or even implementable. Assume a tiny man lives in your computer, he answers to the name "Python Thunk", and he always does the right thing, very quickly.

OK, a 'thunk' is a generalized generator created from an indented suite. A 'thunk' lets us react to control statements inside the thunk (or the lack of control statements).

iter0 = thunk.make_g_iter( [global] [, local] )

makes this generalized iterator, and iter0.next() can return one of these tuples:

('continue', None, None), ('break', None, None), ('nested_continue', None, None), ('nested_break', None, None), ('yield', value, None), ('return', value, dict), ('dead', None, None)

Everything except 'yield' implies that 'dead' will be returned next. Nothing is done to prevent these from being mixed and matched in ways that would never otherwise be allowed.

In a looping situation, it would be typical to call thunk.make_g_iter() for each step of the loop.

These:

thunk.dict( [global] [, local] ) thunk.call( [global] [, local] ) # execute as function

always do the right thing by examining the output of .next(). If they smell a 'generator' ('dead' not returned at the second .next()), they raise an Exception.

There are some subtleties of global and local I am sure I am missing. However, I don't see a problem with 'global' statements in thunks.

This is the cast of characters:

1 function: anon_thunk()

x = f(anon_thunk()) + g(anon_thunk()): ...thunk body...

the less said about this the better

1 line noise operation: magical colon

x = expr: ...thunk body...

which is the same as:

x = expr(anon_thunk()): ...thunk body...

This seems to be popular. Magical line noise ( :*.""",)r" ) is hard for new users to look up the documentation.

2 keywords: thunk_d, thunk_c

thunk_d for "function-like" things thunk_c for "class-like" (???!!!) things

thunk_d: takes "function arguments" in the parenthesis after the name and turns them into a 'arg_helper' function that turns (*args, **kw_args) into a dict suitable for use as a local namespace

thunk_d name(func_a, func_kw_a): expr: ...thunk body...

thunk_c: takes "base classes or whatever" in the parenthesis after the name and turns them into args and kw_args

thunk_c name(a, kw_a): expr: ...thunk body...

2 control keywords: nested_continue, nested_break

these work their way up the frame stack, looking for loops to harass (even if they might be loops in other thunks).

Would a thunk always get the chance to handle 'nested_continue/nested_break' before moving up the frame stack?

I can't get my head around how "try: except:" might be used to handle 'nested_continue/nested_break'.

Happily, we assumed an infinitely wise, infinitely fast creature controlling all this.

*** synchronized example (much hand waving):

for i in sequence: syncronized(mylock): if ...condition...: continue ...more code... if ...condition...: break ...yet more code... if ...condition...: return 42

'synchronized(mylock)' gets the thunk, then does thunk.execute(), and sees if it gets back a 'continue', 'break', or 'return'. Upon seeing a 'continue' or 'break' it issues a 'nested_continue' or 'nested_break' command, which magically works its way up the frame stack to the loop, always being careful to do the right thing.

*** more hand waving

key, record = recordset_loop('rs1'): if no_more_keys: return None, None if key in skip_keys: continue print key print record if key == good_key: return key, record

thunk.next() doesn't care if it is a function, loop, generator, whatever, so why should we? There is the equivalent of a finally: inside recordset_loop, so our recordset gets closed upon Exception.

There is great flexibility in programmatically handling control statements with Python code. I can see how if you use the thunk as a body of a loop, almost any control statement could have a contextual meaning, making it valid to mix them in otherwise unsupported ways.

Should this be allowed? If somebody is willing to write the code to handle all these cases, why shouldn't it be allowed?

*** anon_thunk syntax:

x = expr3(expr2(expr1(anon_thunk()))): ...thunk body...

x = by_hook(anon_thunk()) or by_crook(anon_thunk()): ...thunk body...

a,b = anon_thunk().call(): c = long_expression1(x,y) d = long_expression2(x,y) return min(c,d), max(c,d)

print anon_thunk().dict()['c']: a = 'hello' b = 12 c = '%s%i' % (a,b)

This isn't a syntax so much as it is a lack of syntax. Here is a shambling horror: the super-lambda.

*** property example:

p = property: """thunk.__doc__ docstring""" def get(self): ...body... def set(self, value): ...body...

Whenever I have an object whose name is a key in a dict, I always make the name an attribute in the object too. Usually it is redundant, but when the object is considered outside of the context of the dict, where else would you get its name from? This is why I prefer the uglier "thunk_d myprop: property:"; property gets a chance to the name.

thunk_d myprop: property: """thunk.__doc__ docstring""" def get(self): ...body... def set(self, value): ...body...

'property' is passed tuple ('myprop', None, thunk), and the property is made from thunk.__doc__ and thunk.dict().

*** staticmethod example:

thunk_d mymethod(a1, a2, kw_a1=11, kw_a2=13): staticmethod: """thunk.__doc__ docstring""" ...function body...

'staticmethod' is passed tuple ('mymethod', arg_helper, thunk), where

arg_helper(1,2,3) == { 'a1':1, 'a2':2, 'kw_a1':3, 'kw_a2':13 }

'staticmethod' makes the method from thunk.__doc__, thunk.call(), arg_helper; the method gets assigned to 'mymethod'.

*** class "interface" example:

thunk_c klass1(base1, base2): interface1 + interface2: """thunk.__doc__ docstring""" ...class-like body...

interface3 = interface1 + interface2, and interface3 gets passed (klass1, (base1, base2), kw_args=(), thunk), and makes a class from thunk.dict()

*** other stuff

if anon_thunk(): # not allowed ...thunk body... # not allowed

for i in expr1: # not allowed ...thunk body... # not allowed

x = [: # not allowed ...thunk body... # not allowed ] # not allowed

x = [anon_thunk()]: # sure, why not? ...thunk body... # sure, why not?