Phillip J. Eby wrote:

At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:

...

I was trying to translate a pattern that uses closures in a language like Scheme (where closed values can be written to) to generators using PEP 342, but I'm not clear exactly how it works; the examples in the PEP have different motivations. Since I can't actually run these examples, perhaps someone could confirm or debug these:

A closure based accumulator (using Scheme):

(define (accum n) (lambda (incr) (set! n (+ n incr)) n)) (define s (accum 0)) (s 1) ; -> 1 == 0+1 (s 5) ; -> 6 == 1+5

So I thought the generator version might look like:

def accum(n): while 1: incr = (yield n) or 0 n += incr

Bah, I don't know why this had me so confused. Well, I kind of know why. So maybe this example would be better written: def accum(n): incr = yield # wait to get the first incr to be sent in while 1: n += incr incr = yield n # return the new value, wait for next incr This way it is more explicit all around -- the first call to .next() is just setup, kind of like __init__ in an object, except it has to be explicitly invoked. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

Andrew Koenig wrote:

...

A closure based accumulator (using Scheme):

(define (accum n) (lambda (incr) (set! n (+ n incr)) n)) (define s (accum 0)) (s 1) ; -> 1 == 0+1 (s 5) ; -> 6 == 1+5

So I thought the generator version might look like:

def accum(n): while 1: incr = (yield n) or 0 n += incr

Maybe I'm missing something but this example seems needlessly tricky to me. How about doing it this way?

def accum(n): acc = [n] def f(incr): acc[0] += incr return acc[0] return f

Here, the [0] turns "read-only" access into write access to a list element. The list itself isn't written; only its element is.

I was just exploring how it could be done with coroutines. But also because using lists as pointers isn't that elegant, and isn't something I'd encourage people do to coming from other languages (where closures are used more heavily). More generally, I've been doing some language comparisons, and I don't like literal but non-idiomatic translations of programming patterns. So I'm considering better ways to translate some of the same use cases. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

Le Vendredi 26 Août 2005 16:57, Guido van Rossum a écrit :

On 8/25/05, Ian Bicking wrote:

...

More generally, I've been doing some language comparisons, and I don't like literal but non-idiomatic translations of programming patterns.

True. (But that doesn't mean I think using generators for this example is great either.)

...

So I'm considering better ways to translate some of the same use cases.

Remember that this particuar example was invented to show the superiority of Lisp; it has no practical value when taken literally. If you substitute a method call for the "acc += incr" operation, the Python translation using nested functions is very natural. For larger examples, I'd recommend defining a class as always.

For example, I often use this class to help me in functional programming : _marker = () class var: def __init__(self, v=None): self.v = v def __call__(self, v=_marker): if v is not _marker: self.v = v return self.v and so the nested functions become very functional : def accum(n): acc = var(n) return lambda incr: acc(acc()+incr)