code suite as first class object ?
Sean Ross
sross at connectmail.carleton.ca
Sat Jun 28 22:54:39 EDT 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
thunk"
__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:
[Guido]
> > 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