Some language proposals.

Jacek Generowicz jacek.generowicz at cern.ch
Wed Feb 25 08:54:18 EST 2004


Michael Hudson <mwh at python.net> writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> writes:
> 
> > Paul Prescod <paul at prescod.net> writes:
> > 
> > > I disagree. Closures are rare in Python because Python is primarily an
> > > OOP language.
> > 
> > I disagree, Python is a multi-paradigm language ... I fail to see how
> > this has any bearing on the use of closures ... 
> 
> Really?  Paul is saying "if you are in a situation in Python where you
> want to use a read-write closure, you'll probably be happier if you
> use an object-based solution instead".
> 
> Now you may *disagree* with this point, but I find it hard to believe
> you don't *see* it.

Aaah, OK, _if_ you think that closures are _only_ a way of faking
objects, _then_ claiming that Python is primarily OO does have a
bearing on the use of closures. Forgive me for not pursuing
this tangent any further.

> Using closures to fake objects sucks (in scheme or CL as much as in
> Python).

And using objects (err ... instances of classes) to fake stateful
functions sucks just as much.

When I need "objects" I use objects, and when I need closures I want
to be able to use closures.

> Can you post an example of using a read-write closure that you think
> wouldn't be better off as an object (invent syntax as necessary...).
> No-one was very convincing at this last time it went around on
> python-dev.

Sure. I have some stateful methods of classes (which I create
dynamically and stick onto the class as the information about the
existence of the method becomes available). By implementing them as
closures I can just stick them on to the class. If I were to implement
them as instances then I'd have to reimplement all the descriptors
that take care of turning functions into bound or unbound methods.

[At this point I'd love someone to step up and show me how to re-use
the existing FunctionType descriptors in my own classes.]

Another example. I make quite heavy use of a trivial memoizer. The
closure verison is much shorter, clearer and faster. (I want it to be
writeable because I sometimes want to 'prime' the cache, or do other
things to it ... so I'm giving myself access to the cache by binding
the cache as a function attribute of the closure, before returning it
from the memoizer)

In short, whenever I want a _function_ which happens to have some
internal state, I'd much rather use a closure than an instance of a class.

> > all of which is irrelevant to my original point, which was to note
> > out that saying "people don't use it much" is not a very convincing
> > argument for not fixing something that is broken ... 
> 
> OK, how about the argument above?

My original point, although prompted in a context which discussed
closures, in independent of closures.

[Yes, I happen to wish that closures were writeable as god intended
them to be, dammit :-), but that is completely independent of my
objection to the self-fulfilling prophecy argument.]



More information about the Python-list mailing list