Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #19849 > unrolled thread

Common LISP-style closures with Python

Back to article view | Back to comp.lang.python

Contents

  Common LISP-style closures with Python Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2012-02-04 02:27 +0200
    Re: Common LISP-style closures with Python Chris Rebert <clp2@rebertia.com> - 2012-02-03 18:47 -0800
      Re: Common LISP-style closures with Python Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2012-02-04 12:14 +0200
        Re: Common LISP-style closures with Python Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2012-02-04 12:23 +0200
        Re: Common LISP-style closures with Python Arnaud Delobelle <arnodel@gmail.com> - 2012-02-04 10:58 +0000
          Re: Common LISP-style closures with Python Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2012-02-04 15:09 +0200
            Re: Common LISP-style closures with Python Tomasz Rola <rtomek@ceti.pl> - 2012-02-04 18:42 +0100
        Re: Common LISP-style closures with Python Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-04 17:52 -0500
    Re: Common LISP-style closures with Python John O'Hagan <research@johnohagan.com> - 2012-02-05 12:31 +1100
      Re: Common LISP-style closures with Python Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2012-02-05 06:19 +0200
        Re: Common LISP-style closures with Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-05 13:58 -0700
          Re: Common LISP-style closures with Python Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2012-02-06 07:55 +0200
    Re: Common LISP-style closures with Python Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-05 15:29 -0800
    Re: Common LISP-style closures with Python John Nagle <nagle@animats.com> - 2012-02-09 22:26 -0800
    Re: Common LISP-style closures with Python 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-09 23:55 -0800

#19849 — Common LISP-style closures with Python

In Python textbooks that I have read, it is usually not mentioned that
we can very easily program Common LISP-style closures with Python.  It
is done as follows:

-------------------------------------

# Make a Common LISP-like closure with Python.
#
# Antti J Ylikoski 02-03-2012.

def f1():
     n = 0
     def f2():
         nonlocal n
         n += 1
         return n
     return f2

-------------------------------------

and now we can do:

-------------------------------------

 >>>
 >>> a=f1()
 >>> b=f1()
 >>> a()
1
 >>> a()
2
 >>> a()
3
 >>> a()
4
 >>> b()
1
 >>> b()
2
 >>> a()
5
 >>> b()
3
 >>> b()
4
 >>>

-------------------------------------

i. e. we can have several functions with private local states which
are kept between function calls, in other words we can have Common
LISP-like closures.

yours, Antti J Ylikoski
Helsinki, Finland, the EU

[toc] | [next] | [standalone]

#19852

On Fri, Feb 3, 2012 at 4:27 PM, Antti J Ylikoski <antti.ylikoski@tkk.fi> wrote:
>
> In Python textbooks that I have read, it is usually not mentioned that
> we can very easily program Common LISP-style closures with Python.  It
> is done as follows:
>
> -------------------------------------
>
> # Make a Common LISP-like closure with Python.
> #
> # Antti J Ylikoski 02-03-2012.
>
> def f1():
>    n = 0
>    def f2():
>        nonlocal n
>        n += 1
>        return n
>    return f2
<snip>
> i. e. we can have several functions with private local states which
> are kept between function calls, in other words we can have Common
> LISP-like closures.

Out of curiosity, what would be non-Common-Lisp-style closures?

Cheers,
Chris

[toc] | [prev] | [next] | [standalone]

#19855

On 4.2.2012 4:47, Chris Rebert wrote:
> On Fri, Feb 3, 2012 at 4:27 PM, Antti J Ylikoski<antti.ylikoski@tkk.fi>  wrote:
>>
>> In Python textbooks that I have read, it is usually not mentioned that
>> we can very easily program Common LISP-style closures with Python.  It
>> is done as follows:
>>
>> -------------------------------------
>>
>> # Make a Common LISP-like closure with Python.
>> #
>> # Antti J Ylikoski 02-03-2012.
>>
>> def f1():
>>     n = 0
>>     def f2():
>>         nonlocal n
>>         n += 1
>>         return n
>>     return f2
> <snip>
>> i. e. we can have several functions with private local states which
>> are kept between function calls, in other words we can have Common
>> LISP-like closures.
>
> Out of curiosity, what would be non-Common-Lisp-style closures?
>
> Cheers,
> Chris

I understand that a "closure" is something which is typical of 
functional programming languages.  -- Scheme-style closures, for example.

I don't know Haskell, ML etc. but I do suspect that we could create 
closures in those languages as well.  Maybe someone more expert than me 
can help?

regards, Andy

[toc] | [prev] | [next] | [standalone]

#19856

On 4.2.2012 12:14, Antti J Ylikoski wrote:
> On 4.2.2012 4:47, Chris Rebert wrote:
>> On Fri, Feb 3, 2012 at 4:27 PM, Antti J
>> Ylikoski<antti.ylikoski@tkk.fi> wrote:
>>>
>>> In Python textbooks that I have read, it is usually not mentioned that
>>> we can very easily program Common LISP-style closures with Python. It
>>> is done as follows:
>>>
>>> -------------------------------------
>>>
>>> # Make a Common LISP-like closure with Python.
>>> #
>>> # Antti J Ylikoski 02-03-2012.
>>>
>>> def f1():
>>> n = 0
>>> def f2():
>>> nonlocal n
>>> n += 1
>>> return n
>>> return f2
>> <snip>
>>> i. e. we can have several functions with private local states which
>>> are kept between function calls, in other words we can have Common
>>> LISP-like closures.
>>
>> Out of curiosity, what would be non-Common-Lisp-style closures?
>>
>> Cheers,
>> Chris
>
> I understand that a "closure" is something which is typical of
> functional programming languages. -- Scheme-style closures, for example.
>
> I don't know Haskell, ML etc. but I do suspect that we could create
> closures in those languages as well. Maybe someone more expert than me
> can help?
>
> regards, Andy
>

This is how it is done in standard Common LISP:

-----------------------------------------

;;; Closure with Common LISP.
;;;
;;; Antti J Ylikoski 02-03-2012.

(defun mak-1 ()
   (let ((n 0))
     #'(lambda () (incf n))))

-----------------------------------------

kind regards, Andy

[toc] | [prev] | [next] | [standalone]

#19857

On 4 February 2012 10:14, Antti J Ylikoski <antti.ylikoski@tkk.fi> wrote:
> On 4.2.2012 4:47, Chris Rebert wrote:
>> Out of curiosity, what would be non-Common-Lisp-style closures?
>>
>> Cheers,
>> Chris
>
>
> I understand that a "closure" is something which is typical of functional
> programming languages.  -- Scheme-style closures, for example.
>
> I don't know Haskell, ML etc. but I do suspect that we could create closures
> in those languages as well.  Maybe someone more expert than me can help?

I think what Chris asking is: what is the feature of Common-Lisp
closures that Python closures share but other languages don't?

I think what he is implying is that there is no such feature.  Python
closures are no more "Common-Lisp-style" than they are "Scheme-style"
or "Smalltalk-like" or any other language-like.

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#19858

On 4.2.2012 12:58, Arnaud Delobelle wrote:
> On 4 February 2012 10:14, Antti J Ylikoski<antti.ylikoski@tkk.fi>  wrote:
>> On 4.2.2012 4:47, Chris Rebert wrote:
>>> Out of curiosity, what would be non-Common-Lisp-style closures?
>>>
>>> Cheers,
>>> Chris
>>
>>
>> I understand that a "closure" is something which is typical of functional
>> programming languages.  -- Scheme-style closures, for example.
>>
>> I don't know Haskell, ML etc. but I do suspect that we could create closures
>> in those languages as well.  Maybe someone more expert than me can help?
>
> I think what Chris asking is: what is the feature of Common-Lisp
> closures that Python closures share but other languages don't?
>
> I think what he is implying is that there is no such feature.  Python
> closures are no more "Common-Lisp-style" than they are "Scheme-style"
> or "Smalltalk-like" or any other language-like.
>

I would say that Python closures are equivalent with Common LISP 
closures (except that LAMBDA is more limited in Python, which is a 
feature which I don't like.)

Do you maybe mean non-Common-LISP-style closures in Python?  I cannot 
think of any ones.

kind regards, Andy

[toc] | [prev] | [next] | [standalone]

#19861

On Sat, 4 Feb 2012, Antti J Ylikoski wrote:

> On 4.2.2012 12:58, Arnaud Delobelle wrote:
> > On 4 February 2012 10:14, Antti J Ylikoski<antti.ylikoski@tkk.fi>  wrote:
> > > On 4.2.2012 4:47, Chris Rebert wrote:
> > > > Out of curiosity, what would be non-Common-Lisp-style closures?
> > > >
> > > > Cheers,
> > > > Chris
> > >
> > >
> > > I understand that a "closure" is something which is typical of functional
> > > programming languages.  -- Scheme-style closures, for example.
> > >
> > > I don't know Haskell, ML etc. but I do suspect that we could create
> > > closures
> > > in those languages as well.  Maybe someone more expert than me can help?
> >
> > I think what Chris asking is: what is the feature of Common-Lisp
> > closures that Python closures share but other languages don't?
> >
> > I think what he is implying is that there is no such feature.  Python
> > closures are no more "Common-Lisp-style" than they are "Scheme-style"
> > or "Smalltalk-like" or any other language-like.
> >
> 
> I would say that Python closures are equivalent with Common LISP closures
> (except that LAMBDA is more limited in Python, which is a feature which I
> don't like.)
> 
> Do you maybe mean non-Common-LISP-style closures in Python?  I cannot 
> think of any ones.
> 
> kind regards, Andy

AFAIK there is only one style for closure, similar to one style for 
square. 

There are quite a lot languages implementing closures, and quite a lot try 
to imitate them, including C with non-standard extension (without using 
those imitations I cannot say if they are good enough).

http://en.wikipedia.org/wiki/Closure_(computer_science)

Wrt lambdas, I really like blocks from Ruby (which AFAIK stem from blocks 
in Smalltalk, not sure if they call them "blocks").

http://lesscode.org/2005/07/12/ruby-colored-blocks-in-python/

http://railsguru.org/2010/03/learn-ruby-procs-blocks-lambda/

I mean, myself I am ok with lambdas (using them in languages where lambda 
is welcomed and contributing citizen) but blocks in place of lambdas would 
be nice to have in Python. Introduction of "with" construct was good IMHO, 
but if one likes coding style relying on passing anonymous pieces of code 
then Python might not be good choice for this.

On the other hand, one can argue that using anonymous code too much is not 
the best style. I am not sure if extensive use of blocks/lambdas really 
helps, or if it contributes to "clever" hacks and a source of maintainance 
pain. So, perhaps it is good to have it in a few different ways - 
like, Ruby, Python and CL - and experiment with them all.

In other words, rather than talking about making Python more like some 
other language(s) I think it is much better to learn those other 
language(s). If you'd like to try "unlimited" lambda, you might want to 
play with Racket, a Scheme superset. Or any other Scheme - it's simple 
enough to start coding after a day or two of learning (I mean Fibonaccis 
and Erastotenes sieves, not implementing database or web server).

Myself, I would rather have blocks/lambdas and not need them rather than 
the other way, but that's just me.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

[toc] | [prev] | [next] | [standalone]

#19864

On Sat, Feb 4, 2012 at 5:58 AM, Arnaud Delobelle <arnodel@gmail.com> wrote:
> I think what Chris asking is: what is the feature of Common-Lisp
> closures that Python closures share but other languages don't?
>
> I think what he is implying is that there is no such feature.  Python
> closures are no more "Common-Lisp-style" than they are "Scheme-style"
> or "Smalltalk-like" or any other language-like.

"No such feature"? What's that nonlocal thing then? The above function
could not be written that way in Python 2.

Of course maybe we want to put this feature in another category, but
anyway, the function couldn't be written in some languages, even
though they have closures.

-- Devin

[toc] | [prev] | [next] | [standalone]

#19865

On Sat, 04 Feb 2012 02:27:56 +0200
Antti J Ylikoski <antti.ylikoski@tkk.fi> wrote:

[...]


> 
> # Make a Common LISP-like closure with Python.
> #
> # Antti J Ylikoski 02-03-2012.
> 
> def f1():
>      n = 0
>      def f2():
>          nonlocal n
>          n += 1
>          return n
>      return f2
>
 
[...]

> 
> i. e. we can have several functions with private local states which
> are kept between function calls, in other words we can have Common
> LISP-like closures.
> 

I'm not sure how naughty this is, but the same thing can be done without using
nonlocal by storing the local state as an attribute of the enclosed function
object:

>>> def f():
...     def g():
...             g.count += 1
...             return g.count
...     g.count = 0
...     return g
... 
>>> h = f()
>>> j = f()
>>> h()
1
>>> h()
2
>>> h()
3
>>> j()
1
>>> j()
2
>>> j()
3

This way, you can also write to the attribute:

>>> j.count = 0
>>> j()
1


John

[toc] | [prev] | [next] | [standalone]

#19866

On 5.2.2012 3:31, John O'Hagan wrote:
> On Sat, 04 Feb 2012 02:27:56 +0200
> Antti J Ylikoski<antti.ylikoski@tkk.fi>  wrote:
>
> [...]
>
>
>>
>> # Make a Common LISP-like closure with Python.
>> #
>> # Antti J Ylikoski 02-03-2012.
>>
>> def f1():
>>       n = 0
>>       def f2():
>>           nonlocal n
>>           n += 1
>>           return n
>>       return f2
>>
>
> [...]
>
>>
>> i. e. we can have several functions with private local states which
>> are kept between function calls, in other words we can have Common
>> LISP-like closures.
>>
>
> I'm not sure how naughty this is, but the same thing can be done without using
> nonlocal by storing the local state as an attribute of the enclosed function
> object:
>
>>>> def f():
> ...     def g():
> ...             g.count += 1
> ...             return g.count
> ...     g.count = 0
> ...     return g
> ...
>>>> h = f()
>>>> j = f()
>>>> h()
> 1
>>>> h()
> 2
>>>> h()
> 3
>>>> j()
> 1
>>>> j()
> 2
>>>> j()
> 3
>
> This way, you can also write to the attribute:
>
>>>> j.count = 0
>>>> j()
> 1
>
>
> John

Yes, I do know that, but then it would not be a closure :-)))))))))

Andy

[toc] | [prev] | [next] | [standalone]

#19876

On Sat, Feb 4, 2012 at 9:19 PM, Antti J Ylikoski <antti.ylikoski@tkk.fi> wrote:
>> I'm not sure how naughty this is, but the same thing can be done without
>> using
>> nonlocal by storing the local state as an attribute of the enclosed
>> function
>> object:
>>
>> ...
>
> Yes, I do know that, but then it would not be a closure :-)))))))))

Sure it is.  Where do you think it looks up the function object?

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#19889

On 5.2.2012 22:58, Ian Kelly wrote:
> On Sat, Feb 4, 2012 at 9:19 PM, Antti J Ylikoski<antti.ylikoski@tkk.fi>  wrote:
>>> I'm not sure how naughty this is, but the same thing can be done without
>>> using
>>> nonlocal by storing the local state as an attribute of the enclosed
>>> function
>>> object:
>>>
>>> ...
>>
>> Yes, I do know that, but then it would not be a closure :-)))))))))
>
> Sure it is.  Where do you think it looks up the function object?
>
> Cheers,
> Ian

OK, thank you for correcting me.

Andy

[toc] | [prev] | [next] | [standalone]

#19935

On Feb 3, 6:27 pm, Antti J Ylikoski <antti.yliko...@tkk.fi> wrote:
> In Python textbooks that I have read, it is usually not mentioned that
> we can very easily program Common LISP-style closures with Python.  It
> is done as follows:
> [...]

do my eyes not see nor my ears not hear?
a thread about common Lisp and Xan Lee is not near?
would someone please him wake up and tell him all about,
the thread titled "Common LISP-style closures with Python"
and that he has been left out!

[toc] | [prev] | [next] | [standalone]

#20143

On 2/3/2012 4:27 PM, Antti J Ylikoski wrote:
>
> In Python textbooks that I have read, it is usually not mentioned that
> we can very easily program Common LISP-style closures with Python. It
> is done as follows:

    Most dynamic languages have closures.  Even Perl and Javascript
have closures.  Javascript really needs them, because the "callback"
orientation of Javascript means you often need to package up state
and pass it into a callback.  It really has very little to do with
functional programming.

    If you want to see a different style of closure, check out Rust,
Mozilla's new language.  Rust doesn't have the "spaghetti stack"
needed to implement closures, so it has more limited closure
semantics.  It's more like some of the C add-ons for closures,
but sounder.

					John Nagle

[toc] | [prev] | [next] | [standalone]

#20147

在 2012年2月4日星期六UTC+8上午8时27分56秒，Antti J Ylikoski写道：
> In Python textbooks that I have read, it is usually not mentioned that
> we can very easily program Common LISP-style closures with Python.  It
> is done as follows:
> 
> -------------------------------------
> 
> # Make a Common LISP-like closure with Python.
> #
> # Antti J Ylikoski 02-03-2012.
> 
> def f1():
>      n = 0
>      def f2():
>          nonlocal n
>          n += 1
>          return n
>      return f2
> 
> -------------------------------------
> 
> and now we can do:
> 
> -------------------------------------
> 
>  >>>
>  >>> a=f1()
>  >>> b=f1()
>  >>> a()
> 1
>  >>> a()
> 2
>  >>> a()
> 3
>  >>> a()
> 4
>  >>> b()
> 1
>  >>> b()
> 2
>  >>> a()
> 5
>  >>> b()
> 3
>  >>> b()
> 4
>  >>>
> 
> -------------------------------------
> 
> i. e. we can have several functions with private local states which
> are kept between function calls, in other words we can have Common
> LISP-like closures.
> 
> yours, Antti J Ylikoski
> Helsinki, Finland, the EU

We are not in the 1990's now. A descent  CAD or internet application now should be able to support users with at least one or more   script
languages  easily. Whether it's javascript or java or flash in the browser-based applications, or go, python in the google desktop API, 
commercial SW applications to be able to evolve in the long run  are not jobs from the publishers and the original writers of the SW packages only.

I don't want to include a big fat compiler in my software, 
what else can I do ?
 
 LISP is too fat, too.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web