What does you, the viewer, think? One way or another, BOO-503 will come to pass, so do not ph33r the inevitable.

I was thinking about what kind of attributes could be used to uniquely name a closure while still giving enough context someone trying to debug a problem, and thought of this:

"__ParentClass.Closure_LINE_COLUMN"
class t:
def method():
z = { }

This would be: __t.Closure_3_15

This way is undeniably specific; you know where, exactly, this particular closure was declared. Its not very friendly to the eyes, though.

Another way is,

__ParentClass.LocalNameClosure/Callable_LINE_COLUMN

So now it would looke like, __t.zClosure_3_15

Now its a little more distinct, and if the variable is uniquely named enough I can just go to that particular chunk of the source code and search for it.

What happens to this, though?

a = { print 'wtfpwned' }
a = { print 'another closure entirely' }

What should the second closure be named? If we follow the second set of suggested naming rules, then we've got two closures named very similarly.

They are distinct, of course, __aClosure_1_1 and __aClosure_2_2.

With the first form, you don't have that sort of potential visual confusion, but you lack the potential ease of use of identifying them by parameter name.

With the second form, its vice versa.

Hm.

Edit the patch to suit your tastes.

c1 = {"Name:FirstMethod"; print("c1")}
c1()

c2 = def(x as int):
"""Name: AnotherMethod
Some other documentation..."""
print "c2", x
c2(3)

The patch looks really nice!

public event SomeEvent as callable(sender, e as SomeEventArgs)

That would generate the following in the type where it is defined.

public callable SomeEventHandler(sender as object, e as SomeEventArgs) as void

Right now, this is supported:
public event SomeEvent as callable(object, SomeEventArgs), which generates some ugly delegates with arg0, arg1, etc. as parameters.