6 ms·

Can you not redefine a method in Python's shell in the exact same method? Edit: Ah...silly me, that isn't exactly runtime.

brudgers 9y ago
Right. If I have the Python code to parallel the Common Lisp: import time def drill(n, f): for i in range(0, n): f(i) time.sleep(1) def gen(n): print(n) drill(10, gen) I get: $> python3 interrupt.py 0 1 2 3 ^CTraceback (most recent call last): File "interrupt.py", line 11, in <module> drill(10, gen) File "interrupt.py", line 6, in drill time.sleep(1) KeyboardInterrupt $> The funny thing is though I've known it was possible to redefine running Common Lisp code and I have seen the Continue option many times, it really wasn't clear why it would be used and in part because it is mostly ignored in descriptions of Common Lisp. I mean the behavior isn't described in the SBCL User Manual. Nor is it really fleshed out in the Common Lisp HyperSpec http://www.lispworks.com/documentation/HyperSpec/Body/f_abortc.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_abor...
- hardenedapple 9y ago
  As a curiosity/hack you can almost get there with pyrasite (https://github.com/lmacken/pyrasite https://github.com/lmacken/pyrasite) and def newfn(): ... oldfn.__code__ = newfn.__code__ del newfn There's a difficulty with __globals__ and __closures__ but I found the patch at the end of this post https://hardenedapple.github.io/stories/computers/python_function_override/ https://hardenedapple.github.io/stories/computers/python_fun... appears to allow full redefinition. Disclaimer: I'm pretty confident there will be edge cases and/or bugs with these approaches.
  - armitron 9y ago
    Even when it comes to simple function redefinition, Python is __nowhere near__ the flexibility of Common Lisp and that's why things like pyrasite are gimmicks and seldom used in the wild. The underlying reason is twofold: + Python lacks symbols + The Python module system is very simplistic Symbols allow CL to abstract how variable/function access takes place [through the symbol]. Thus, when you change a function's code, everyone that was using the function (through its symbol) will transparently see the change. In Python there are no symbols but references. When you change the code of the function, you have to manually update all references to point to the new code. If you also take into account the primitive module system that Python throws at you, it gets really messy really fast. Function redefinition in Common Lisp is part of what makes CL great and the language development environments are geared around it. In sort, Common Lisp developers use it all the time, it's not a gimmick. I never build my full Python programs at the Python REPL, by keeping a single Python process live and iteratively changing its state. I experiment at the Python REPL, sure, but it's so crude and primitive (and the language of course fights you on this by not being geared around interactive development of this sort) that it's impossible to work in the fashion I just described. When I build a program in Common Lisp, the Lisp process is always live, always running. I am always working inside it and it feels natural and easy. And of course, this is just one small thing out of the entire 'interactivity' picture when it comes to CL. The condition system, the object system, the reader, the compiler (available at runtime) and compiler macros ... there is absolutely nothing that comes close to what Common Lisp offers in terms of interactivity today (except maybe Smalltalk which has issues with performance, Forth and to a much more limited extent, Erlang). I feel that people who point to Python/Ruby/Javascript REPLs or Java/.Net as realistic alternatives when it comes to interactive development and rapid prototyping, have either no experience with or absolutely no understanding of what Common Lisp offers.
    - flavio81 9y ago
      > except maybe Smalltalk which has issues with performance, Forth and to a much more limited extent, Erlang Just to add to the "performance" aspect, Lisp, with modern compiler like SBCL, is generally close or at the same speed as Java (under Oracle's JVM). Which is pretty good.
- tom_mellior 9y ago
  This isn't a very fair comparison as the Lisp code is shown running in the REPL, not in some sort of release mode that, even in Lisp, would presumably not drop you into the REPL. It's fairer to ask for interactive mode, in which you can redefine things and restart your tests: $ python3 -i interrupt.py 0 1 2 ^CTraceback (most recent call last): File "interrupt.py", line 12, in <module> drill(10, gen) File "interrupt.py", line 7, in drill time.sleep(1) KeyboardInterrupt >>> def gen(n): ... print('{}!'.format(n)) ... >>> drill(10, gen) 0! 1! 2! 3! ^CTraceback (most recent call last): File "<stdin>", line 1, in <module> File "interrupt.py", line 7, in drill time.sleep(1) KeyboardInterrupt >>> What's magic about the Lisp version is not the "in debug mode, you get a REPL and can redefine stuff" part. What's magic about the Lisp version is the "you can then continue the test where you left off" part. That's impossible in Python because exceptions unwind the stack.
  - juki 9y ago
    Lisp doesn't really have separate release/debug modes[1]. When you want to distribute a program as a binary, you dump the image and set a custom top-level function to use instead of the default REPL. The program will still contain the compiler/interpreter and can redefine everything just like during development (altough the program might not use or expose those features to the user). The REPL isn't in any way magical in Lisp; it's just the default option for interacting with the Lisp. [1]: You can ask the Lisp to drop all debug information as an optimization, which makes development impractical, but still possible. Some implementation might allow you to distribute a program without the compiler, but the standard does not specify that.
    - pjmlp 9y ago
      This is why I usually speak of JIT for development and AOT for distribution, as a model.
    - lispm 9y ago
      Lisp doesn't have that in the language standards, but Lisp implementations provide that. Lisp developers had the problem of shipping smaller applications, shipping faster applications to end customers, targetting systems where GC is problematic, or deploying on embedded systems. Lisps with extensive image-based delivery support are for example Allegro CL and LispWorks. Delivery here means also deep cuts into the software like removing parts of the Lisp system (everything development relatied, unused functionality, ...) and also removing parts of the program for the delivered application. For example the running program might not need much of the program's symbols. Functions would be called directly and not through symbols. There are also compilers for application delivery (some are inhouse) which generate self-contained C code. These then are compiled with the usual C compiler and generate small static applications. An example would be mocl, which can compile for Android, iOS and macOS platforms.

brudgers 9y ago

Right. If I have the Python code to parallel the Common Lisp: import time def drill(n, f): for i in range(0, n): f(i) time.sleep(1) def gen(n): print(n) drill(10, gen) I get: $> python3 interrupt.py 0 1 2 3 ^CTraceback (most recent call last): File "interrupt.py", line 11, in <module> drill(10, gen) File "interrupt.py", line 6, in drill time.sleep(1) KeyboardInterrupt $> The funny thing is though I've known it was possible to redefine running Common Lisp code and I have seen the Continue option many times, it really wasn't clear why it would be used and in part because it is mostly ignored in descriptions of Common Lisp. I mean the behavior isn't described in the SBCL User Manual. Nor is it really fleshed out in the Common Lisp HyperSpec http://www.lispworks.com/documentation/HyperSpec/Body/f_abortc.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_abor...

hardenedapple 9y ago
As a curiosity/hack you can almost get there with pyrasite (https://github.com/lmacken/pyrasite https://github.com/lmacken/pyrasite) and def newfn(): ... oldfn.__code__ = newfn.__code__ del newfn There's a difficulty with __globals__ and __closures__ but I found the patch at the end of this post https://hardenedapple.github.io/stories/computers/python_function_override/ https://hardenedapple.github.io/stories/computers/python_fun... appears to allow full redefinition. Disclaimer: I'm pretty confident there will be edge cases and/or bugs with these approaches.
- armitron 9y ago
  Even when it comes to simple function redefinition, Python is __nowhere near__ the flexibility of Common Lisp and that's why things like pyrasite are gimmicks and seldom used in the wild. The underlying reason is twofold: + Python lacks symbols + The Python module system is very simplistic Symbols allow CL to abstract how variable/function access takes place [through the symbol]. Thus, when you change a function's code, everyone that was using the function (through its symbol) will transparently see the change. In Python there are no symbols but references. When you change the code of the function, you have to manually update all references to point to the new code. If you also take into account the primitive module system that Python throws at you, it gets really messy really fast. Function redefinition in Common Lisp is part of what makes CL great and the language development environments are geared around it. In sort, Common Lisp developers use it all the time, it's not a gimmick. I never build my full Python programs at the Python REPL, by keeping a single Python process live and iteratively changing its state. I experiment at the Python REPL, sure, but it's so crude and primitive (and the language of course fights you on this by not being geared around interactive development of this sort) that it's impossible to work in the fashion I just described. When I build a program in Common Lisp, the Lisp process is always live, always running. I am always working inside it and it feels natural and easy. And of course, this is just one small thing out of the entire 'interactivity' picture when it comes to CL. The condition system, the object system, the reader, the compiler (available at runtime) and compiler macros ... there is absolutely nothing that comes close to what Common Lisp offers in terms of interactivity today (except maybe Smalltalk which has issues with performance, Forth and to a much more limited extent, Erlang). I feel that people who point to Python/Ruby/Javascript REPLs or Java/.Net as realistic alternatives when it comes to interactive development and rapid prototyping, have either no experience with or absolutely no understanding of what Common Lisp offers.
  - flavio81 9y ago
    > except maybe Smalltalk which has issues with performance, Forth and to a much more limited extent, Erlang Just to add to the "performance" aspect, Lisp, with modern compiler like SBCL, is generally close or at the same speed as Java (under Oracle's JVM). Which is pretty good.
tom_mellior 9y ago
This isn't a very fair comparison as the Lisp code is shown running in the REPL, not in some sort of release mode that, even in Lisp, would presumably not drop you into the REPL. It's fairer to ask for interactive mode, in which you can redefine things and restart your tests: $ python3 -i interrupt.py 0 1 2 ^CTraceback (most recent call last): File "interrupt.py", line 12, in <module> drill(10, gen) File "interrupt.py", line 7, in drill time.sleep(1) KeyboardInterrupt >>> def gen(n): ... print('{}!'.format(n)) ... >>> drill(10, gen) 0! 1! 2! 3! ^CTraceback (most recent call last): File "<stdin>", line 1, in <module> File "interrupt.py", line 7, in drill time.sleep(1) KeyboardInterrupt >>> What's magic about the Lisp version is not the "in debug mode, you get a REPL and can redefine stuff" part. What's magic about the Lisp version is the "you can then continue the test where you left off" part. That's impossible in Python because exceptions unwind the stack.
- juki 9y ago
  Lisp doesn't really have separate release/debug modes[1]. When you want to distribute a program as a binary, you dump the image and set a custom top-level function to use instead of the default REPL. The program will still contain the compiler/interpreter and can redefine everything just like during development (altough the program might not use or expose those features to the user). The REPL isn't in any way magical in Lisp; it's just the default option for interacting with the Lisp. [1]: You can ask the Lisp to drop all debug information as an optimization, which makes development impractical, but still possible. Some implementation might allow you to distribute a program without the compiler, but the standard does not specify that.
  - pjmlp 9y ago
    This is why I usually speak of JIT for development and AOT for distribution, as a model.
  - lispm 9y ago
    Lisp doesn't have that in the language standards, but Lisp implementations provide that. Lisp developers had the problem of shipping smaller applications, shipping faster applications to end customers, targetting systems where GC is problematic, or deploying on embedded systems. Lisps with extensive image-based delivery support are for example Allegro CL and LispWorks. Delivery here means also deep cuts into the software like removing parts of the Lisp system (everything development relatied, unused functionality, ...) and also removing parts of the program for the delivered application. For example the running program might not need much of the program's symbols. Functions would be called directly and not through symbols. There are also compilers for application delivery (some are inhouse) which generate self-contained C code. These then are compiled with the usual C compiler and generate small static applications. An example would be mocl, which can compile for Android, iOS and macOS platforms.