Python doesn't work well for repl development. You cannot set the current module in Python as you can do in Lisp. So you're restricted to make changes to the current module. Also, debugging in the repl is not as powerful in Python.

Sure it does. Just paste the defs into the repl.

You can also use `from importlib import reload` and then have an expression like reload(foo).bar() to constantly reload your foo library.

But this means you have to litter your application with support for it, doesn't it? In Common Lisp, I can stop at a breakpoint, paste in a new definition of any function in the application, and then resume and it will use the new definition everywhere rather than the one that existed when the breakpoint was triggered: https://two-wrongs.com/debugging-common-lisp-in-slime.html

*and not only paste, but write, in the source file, the new definition, re-compile it (C-c C-c), and resume execution from a stackframe before this call. (a clarification for folks who would think we must paste in the REPL)

That's useful not only for breakpoints but for errors. We can fix an error without re-running everything from zero. https://www.youtube.com/watch?v=jBBS4FeY7XM

Reload only reloads one copy of the module. If there are other modules that imported the same module, your new definition will not be seen by them unless you find all the copies of foo in memory and reload them also. Since there's no reliable way to do that, you're more likely to just restart Python all the time.

Not accurate as worded. Python caches module imports in `sys.modules`, so all imports get the same one. A `reload()` will reuse the same dict object that was being used as the module's namespace, so everything with a reference to the module object will see the same namespace and get the updates.

This is basically either ignorance or a lie spread by lispers but you're wrong. You can look through my history and find my last slap fight with someone proclaiming SLIME as the one true repl. The only thing you can't do in Python (or any other sane language that I know about) that you can do in lisp is catch a stack unwind due to error (you can only break as the stack is being unwound).

Whoa, please don't take HN threads into programming language flamewars, "slap fights", or attacks on other users. We're trying to avoid all that here.

https://news.ycombinator.com/newsguidelines.html

I didn't say this should be a slap fight - I said the last one was. I'm always at a loss with how reading comprehension should lead people to conclude X here but instead they conclude Y. Like it literally says the previous one ie I don't know how I could've made it any clearer.

Also you're perpetual quoting of the rule book under the guise of "here's our credo" doesn't accomplish anything because it doesn't clarify what rule was broken (and just serves to obscure the censure under "we don't like your kind around here"). At minimum you should cite exactly what rule was broken.

You broke the rules against flamebait and calling names.

If you'd just make your comments less aggressive, it would be much better.

Check out lpy-mode

What? Yes you can. I do it all the time.

    import code; code.interact(local=vars(foo))

where `foo` is the module object you want to set as current. This launches a subREPL in that module's namespace. (EOF kills the subREPL and returns to main.)

Python has a debugger in the standard library that can also do post-mortem inspections.

I'm trying to convince myself Jupyter isn't a form of living in the REPL expressed through tabbed state in a linear order, of python execution. I think it is, but I suspect it fails some boundary condition of significance. That said, when I did it, I didn't find it too hard to introspect on my code, in what it told me.

I do think there is a meta going on around LISP repl and it's internal introspection which other REPL don't quite provide. You can come to almost the same place in output, but not at interaction with the run state of the 'machine' itself. (somebody else in the thread made the point its mostly there except handling exceptions in the stack)

Jupyter Notebooks are absolutely a form of REPL, the type pioneered by MACSYMA, cloned by Mathematica, and significantly enhanced by Symbolics Dynamic Windows and Common Lisp Interface Manager (which is basically just DW but for any Common Lisp with CLOS).

Try redefining something from a library that is used from a lot of different places. It's easy to change one copy of a definition in Python, but the only way to get all of them is to write your new definition to disk and restart Jupyter.

I think you can argue that the pervasive use of notebooks is close enough for learning at least, but it's not as good for real development. The edit-and-continue features in Visual Studio for C# (and similar feature in Java) is the closest non-lisp thing we have these days. The languages aren't made for it like lisp are though, you have to do full restarts all the time.

I still wish there was an environment more like Smalltalk for Python.

>The edit-and-continue features in Visual Studio for C# (and similar feature in Java) is the closest non-lisp thing we have these days.

Some years ago I was playing around with Franz Lisp, and noticed an interesting debugging feature in it. A few days later, I was using a then-new version of Visual Studio for writing either C (not C++) or VB, and noticed the same cool feature in it, which MS was calling Edit and Continue.

IIRC, it was introduced in that VS version, but not sure, since I was not a regular Visual Studio user.

On Microsoft ecosystem, it was initially introduced in VB.

Interesting.

Shameless plug: I have always been fascinated by edit-and-continue and I build a JavaScript IDE centered around it.

https://leporello.tech/

test driven development has been around since the late 90s and was popularised in eXtreme Programming circles, are you sure it's a fad? I find it the most efficient way to write code and keep it running in the long term personally.

You simply can't in Python, not only due to unwind-first exception handling, but also because one module is represented by multiple objects in memory: one object for each other module that imports it. That makes it impossible to redefine anything (you'll always miss some of the copies of whatever you tried to redefine). Importing things from modules piecemeal makes it even harder to find them.

The importlib.reload function only applies to one copy of a module. A comprehensive solution would be incredibly complicated and would still have limitations.

In contrast, a Lisp package exists in exactly one place. No matter where you get it from, two references to the same package are always eq (having "is" equality in Python terms). Therefore, if you redefine something in a package, you redefine it for everything that uses the package. It also helps that imports in Lisp apply to the symbols, not the things they refer to. So importing something doesn't hide a copy of it anywhere. The most naive redefinition technique will always work, with no edge cases.

The inability for class redefinition to affect already existing objects in Python is another severe limitation. Even if you could redefine anything reliably in Python, you'd still have this problem.

I do a lot of python halted in the debugger, which is a close enough approximation.

I do! I have been using Common Lisp since 1982, love it. But when I code in Python, Emacs with the old Python support gives you a really nice editing and REPL environment.