Some language proposals.

Michael Hudson mwh at python.net
Wed Feb 25 13:09:34 EST 2004


Jacek Generowicz <jacek.generowicz at cern.ch> writes:

> 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.

OK, you really hadn't seen this argument before.  You must be new here
:-) (or at least, new to this particular dispute).

> > 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.

Hmm.  Really?  I'm not sure that I often find myself wanting a
"stateful function".  I think I probably usually use bound methods.
This could be the tail wagging the dog, of course.

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

So could this :-) 

(trivially, you never *need* closures, just the same as you don't
*need* objects, there's a rather dull and unhelpful isomorphism
between the two concepts).

> > 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.

Which isn't that hard... I think a code example might lend a bit more
clarity.

> [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.]

Post some code, and I'll have a go.

> Another example. I make quite heavy use of a trivial memoizer. The
> closure verison is much shorter, clearer and faster.

I'll grant you this: I've done the same.

> (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)

Um, here, unless I misunderstand you, you don't want to mutate the
closed over binding (which is what Python currently doesn't let you
do) but mutate the object the closed over binding is bound to.  In
this respect, Python is no different from anything else, you need to
arrange some way to expose said object outside the closure.

What am I missing?

> 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.

Maybe, once you've been assimilated into the Python Borg mindset, you
don't, actually.

There are sort of two extreme possibilities here:

1) I am so blinded by the fact that I know Python as of 2.3 FAR better
   than any other language that I don't see how wonderful Python would
   be if "full closures" were added.

2) Full closures just aren't that appropriate to Pythonic programming.

The truth, almost certainly, is somewhere in between these points.

> > > 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.

Fine.  Let's have a real argument instead :-)

Cheers,
mwh

-- 
  Never meddle in the affairs of NT. It is slow to boot and quick to
  crash.                                             -- Stephen Harris
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html



More information about the Python-list mailing list