[Python-Dev] anonymous blocks

Michael Sparks Michaels at rd.bbc.co.uk
Wed Apr 20 14:24:05 CEST 2005

On Tuesday 19 Apr 2005 20:24, Guido van Rossum wrote:
> *If* we're going to create syntax for anonymous blocks, I think the
> primary use case ought to be cleanup operations to replace try/finally
> blocks for locking and similar things. I'd love to have syntactical
> support so I can write
> blahblah(myLock):
>     code
>     code
>     code

I've got a basic parser that I wrote last summer which was an experiment in a 
generic "python-esque" parser. It might be useful for playing with these 
thing since it accepted the above syntax without change, among many others, 
happily. (Added as a 38th test, and probably the sixth "language syntax" it 

It's also entirely keyword free, which strikes me as a novelty.

The abstract syntax tree that's generated for it is rather unwieldy and over 
the top, but that's as far as the parser goes. (As I said I was interested in 
a generic parser, not a language :)

The (entire) grammar resulting was essentially this: (and is LR-parsable)

program -> block
block -> BLOCKSTART statement_list BLOCKEND
statement_list -> statement*
statement -> (expression | expression ASSIGNMENT expression | ) EOL
expression -> oldexpression (COMMA expression)*
oldexpression -> (factor [factorlist] |  factor INFIXOPERATOR expression )
factorlist -> factor* factor 
factor -> ( bracketedexpression | constructorexpression | NUMBER | STRING | ID
          | factor DOT dotexpression | factor trailer | factor trailertoo )
dotexpression -> (ID bracketedexpression | factor )
bracketedexpression -> BRA [ expression ] KET
constructorexpression -> BRA3 [ expression ] KET3
trailer -> BRA2 expression KET2
trailertoo -> COLON EOL block

The parser.out file for the curious is here:
   * http://www.cerenity.org/SWP/parser.out   (31 productions)

The parser uses a slightly modified PLY based parser and might be useful for 
playing around with constructs (Might not, but it's the reason I'm mentioning 

The approach taken is to treat ":" as always starting a code block to be 
passed. The first token on the line is treated as a function name. The idea 
was that "def", "class", "if", etc then become simple function calls that get 
various arguments which may include one or more code blocks.

The parser was also written entirely test first (as an experiment to see
what that's like for writing a parser) and includes a variety of sample
programs that pass. (39 different program tests)

I've put a tarball here:
   * http://www.cerenity.org/SWP-0.0.0.tar.gz (includes the modifed version of

   * Also browesable here:

   * Some fun examples: 
      * Python-like http://www.cerenity.org/SWP/progs/expr_29.p
        (this example is an earlier version of the parser)
      * LOGO like: http://www.cerenity.org/SWP/progs/expr_33.p
      * L-System definition: http://www.cerenity.org/SWP/progs/expr_34.p
      * SML-like: http://www.cerenity.org/SWP/progs/expr_35.p
      * Amiga E/Algol like: http://www.cerenity.org/SWP/progs/expr_37.p

Needs the modified version of PLY installed first, and the tests can be run 
using "runtests.sh".

Provided in case people want to play around with something, I'm happy with the 
language as it is. :-)

Best Regards,

Michael Sparks, Senior R&D Engineer, Digital Media Group
Michael.Sparks at rd.bbc.co.uk,
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail may contain personal views which are not the views of the BBC.

More information about the Python-Dev mailing list