code suite as first class object ?

Sean Ross sross at
Sun Jun 29 04:54:39 CEST 2003

I've been thinking about something like this (though not exactly) for the
last few weeks. I did a post ("PEP318 - property as decoration"), where
(amongst other things) I suggested it would be possible to define properties
cleanly using blocks and/or thunks. This idea was based on a discussion from
python-dev in January/February ("Extended Function Syntax"). Blocks and
thunks (as I saw them) seemed powerful. The way I was thinking about them,
it looked like it might be possible to define anonymous functions, and even
anonymous classes. From there, I began toying with a language design that
focused on trying to use only namespaces, bindings, generators, blocks and
thunks (oh, and numbers and strings and lists, etc). I haven't quite worked
out the kinks, but it looks something like Smalltalk with bits and pieces of
Icon, Ruby, and Python thrown in. The idea I was trying to work out was "If
Python were to add thunks (as I pictured them), how could that affect the
language? What sorts of things could I expect to see people trying with
their code?".  In other words, "How bad could it get?".  Here's an example:

MyClass = object with:
        "MyClass = object(thunk), where object returns a class defined using

        __init__ = method with self, foo:
                "__init__ = method(thunk), where method returns a method
defined using thunk"
                self._foo = foo

        foo = property with:
                "property foo's docstring"
                fget = with self:
                        return self._foo
                fset = with self, value:
                        self._foo = value

        bar = static, method with:
                "bar = static(method(thunk))"
                1.upto(10) do with i:
                        print "upto() yeilds %d which is passed to the
thunk. The thunk is passed to do (do(thunk)) ",  \
                                 "where it gets executed, and so you see
this!" % i

So, the language I was working out was not Python as it is now, but as it
might become should something like blocks and thunks be added. I don't find
the language terrible, but I also don't find it to be Python - and that's my
point, I suppose. I like the idea of blocks and thunks and anonymous
functions, classes, etc., but I don't like the idea that there could be more
than one way to define a function, method, or class.

If you read the python-dev discussions, the ideas presented for thunks
appear to enable macro programming as well. For instance, using Guido's
definition of thunks he was able to construct a switch statement, but not
like yours, like this:

> >   switch(expr):
> >     case(val1):
> >       block1
> >     case(val2):
> >       block2
> >     default:
> >       block3
> >

To which he added:

> > This actually makes me worry -- I didn't plan thunks to be the answer
> > to all problems.  A new idea that could cause a paradigm landslide is
> > not necessarily right.

A statement I'd have to say I agree with.

More information about the Python-list mailing list