I've been following this conversation, and it sounds to me as if we are stumbling about in the dark, trying to feel our way toward something very useful and powerful. I think Jim is right, what we're feeling our way toward is macros.

The problem, of course, is that Guido (and others!) are on record as being opposed to adding macros to Python. (Even "good" macros... think lisp, not cpp.) I am not quite sure that I am convinced by the argument, but let me see if I can present it:

Allowing macros in Python would enable individual programmers or groups to easily invent their own "syntax". Eventually, there would develop a large number of different Python "dialects" (as some claim has happened in the Lisp community) each dependent on macros the others lack. The most important casualty would be Python's great *readability*.

(If this is a strawman argument, i.e. if you know of a better reason for keeping macros OUT of Python please speak up. Like I said, I've never been completely convinced of it myself.)

Nor am I; though I am also not completely unconvinced! The argument as presented here is probably to generic; taken literally, it would argue against having functions and classes as well... My problem with macros is actually more practical: Python's compiler is too dumb. I am assuming that we want to be able to import macros from other modules, and I am assuming that macros are expanded by the compiler, not at run time; but the compiler doesn't follow imports (that happens at run time) so there's no mechanism to tell the compiler about the new syntax. And macros that don't introduce new syntax don't seem very interesting (compared to what we can do already).

I think it would be useful if we approached it like this: either what we want is the full power of macros (in which case the syntax we choose should be guided by that choice), or we want LESS than the full power of macros. If we want less, then HOW less?

In other words, rather than hearing what we'd like to be able to DO with blocks, I'd like to hear what we want to PROHIBIT DOING with blocks. I think this might be a fruitful way of thinking about the problem which might make it easier to evaluate syntax suggestions. And if the answer is that we want to prohibit nothing, then the right solution is macros.

I'm personally at a loss understanding your question here. Perhaps you could try answering it for yourself? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 4/25/05, Michael Chermside wrote:

I've been following this conversation, and it sounds to me as if we are stumbling about in the dark, trying to feel our way toward something very useful and powerful. I think Jim is right, what we're feeling our way toward is macros.

I think the key difference with macros is that they act at compile time, not at run time. There is no intention here to provide any form of compile-time processing, and that makes all the difference. What I feel is the key concept here is that of "injecting" code into a template form (try...finally, or try..except..else, or whatever) [1]. This is "traditionally" handled by macros, and I see it as a *good* sign, that the discussion has centred around runtime mechanisms rather than compile-time ones. [1] Specifically, cases where functions aren't enough. If I try to characterise precisely what those cases are, all I can come up with is "when the code being injected needs to run in the current scope, not in the scope of a template function". Is that right? Paul.

Michael Chermside wrote:

Jim Jewett writes:

...

As best I can tell, the anonymous blocks are used to take care of boilerplate code without changing the scope -- exactly what macros are used for.

Folks, I think that Jim is onto something here.

I've been following this conversation, and it sounds to me as if we are stumbling about in the dark, trying to feel our way toward something very useful and powerful. I think Jim is right, what we're feeling our way toward is macros.

I am very excited about the discussion of blocks. I think they can potentially address two things that are sticky to express in python right now. The first is to compress the common try/finally use cases around resource usage as with files and database commits. The second is language extensibility, which makes us think of what macros did for Lisp. Language extensibility has two motivations. First and foremost is to allow the programmer to express his or her *intent*. The second motivation is to reuse code and thereby increase productivity. Since methods already allow us to reuse code, our motivation is to increase expressivity. What blocks offer is to make Python's suites something a programmer can work with. Much like using a metaclass putting control of class details into the programmer's hands. Or decorators allowing us to modify method semantics. If the uses of decorators tells us anything, I'm pretty sure there are more potential uses of blocks than we could shake many sticks at. ;) So, the question comes back to what are blocks in the language extensibility case? To me, they would be something very like a code object returned from the compile method. To this we would need to attach the globals and locals where the block was from. Then we could use the normal exec statement to invoke the block whenever needed. Perhaps we could add a new mode 'block' to allow the ControlFlow exceptions mentioned elsewhere in the thread. We still need to find a way to pass arguments to the block so we are not tempted to insert them in locals and have them magically appear in the namespace. ;) Personally, I'm rather attached to "as (x, y):" introducing the block. To conclude, I mocked up some potential examples for your entertainment. ;) Thanks for your time and consideration! -Shane Holloway Interfaces:: def interface(interfaceName, *bases, ***aBlockSuite): blockGlobals = aBlockSuite.globals().copy() blockGlobals.update(aBlockSuite.locals()) blockLocals = {} exec aBlock in blockGlobals, blockLocals return iterfaceType(interfaceName, bases, blockLocals) IFoo = interface('IFoo'): def isFoo(self): pass IBar = interface('IBar'): def isBar(self): pass IBaz = interface('IBaz', IFoo, IBar): def isBaz(self): pass Event Suites:: def eventSinksFor(events, ***aBlockSuite): blockGlobals = aBlockSuite.globals().copy() blockGlobals.update(aBlockSuite.locals()) blockLocals = {} exec aBlock in blockGlobals, blockLocals for name, value in blockLocals.iteritems(): if aBlockSuite.locals().get(name) is value: continue if callable(value): events.addEventFor(name, value) def debugScene(scene): eventSinksFor(scene.events): def onMove(pos): print "pos:", pos def onButton(which, state): print "button:", which, state def onKey(which, state): print "key:", which, state

Michael Chermside wrote:

In other words, rather than hearing what we'd like to be able to DO with blocks, I'd like to hear what we want to PROHIBIT DOING with blocks. I think this might be a fruitful way of thinking about the problem which might make it easier to evaluate syntax suggestions. And if the answer is that we want to prohibit nothing, then the right solution is macros.

One thing we don't need, I believe, is arbitrary transformation of code objects. That's actually already possible, thanks to Python's compiler module, although the method isn't clean yet. Zope uses the compiler module to sandbox partially-trusted Python code. For example, it redirects all print statements and replaces operations that change an attribute with a call to a function that checks access before setting the attribute. Also, we don't need any of these macros, AFAICT: http://gauss.gwydiondylan.org/books/drm/drm_86.html Shane

Michael Chermside wrote:

if the answer is that we want to prohibit nothing, then the right solution is macros.

I'm not sure about that. Smalltalk manages to provide very reasonable-looking user-defined control structures without using compile-time macros, just normal runtime evaluation together with block arguments. It does this by starting out with a fairly minimal and very flexible syntax. This raises the question of why people feel the need for macros in Lisp or Scheme, which have an even more minimal and flexible syntax. I think part of the reason is that the syntax for passing an unevaluated block is too obtrusive. In Scheme you can define a function (not macro) that is used like this: (with-file "foo/blarg" (lambda (f) (do-something-with f))) But there is a natural tendency to want to be able to cut out the lambda cruft and just write something like: (with-file "foo/blarg" (f) (do-something-with f)) and for that you need a macro. The equivalent in Smalltalk would be something like File open: "foo/blarg" do: [:f f something] which doesn't look too bad (compared to the rest of the language!) because the block-passing syntax is fairly unobtrusive. So in summary, I don't think you necessarily *need* macros to get nice-looking user-defined control structures. It depends on other features of the language. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+