Live data from Hacker News

PEP 762 – REPL-acing the default REPL

peps.python.org

21–30 of 88 posts

Re: PEP 762 – REPL-acing the default REPL

#22

I want a Lisp-like REPL for my Python programs that is available to the user who runs my compiled Python program (so, I want compilation as well). The user will be able to interact with my program (instead of just running the main function), change function definitions, etc. and mold the program to their specific use case while it's running.

Something like https://hylang.org/ ? I suppose it won't work with compiled code though.

Re: PEP 762 – REPL-acing the default REPL

#24
post #15

Earlier quoted context omitted.

Some things are a bit awkward, but what specifically can't you really do in a Python REPL? You can dynamically overwrite functions in an imported module, you can re-import modules with importlib, etc. I ask because my Lisp experience is limited.

Lisp REPL keeps the state of the program because it is a live image. With Python REPL you need to rerun the program to set the variables to their values.

You can create a file, example.py:

    import time
    value = "foo"
    def go():
      for i in range(10):
        print("...", i, value)
        time.sleep(3)
Then, in repl,

    import example
    import threading
    thread = threading.Thread(target=example.go)
    thread.start()
It will slowly print out messages and you can do "example.value = 'bar'" in the REPL and it will change.

Re: PEP 762 – REPL-acing the default REPL

#25
post #24

Earlier quoted context omitted.

Lisp REPL keeps the state of the program because it is a live image. With Python REPL you need to rerun the program to set the variables to their values.

You can create a file, example.py: import time value = "foo" def go(): for i in range(10): print("...", i, value) time.sleep(3) Then, in repl, import example import threading thread = threading.Thread(target=example.go) thread.start() It will slowly print out messages and you can do "example.value = 'bar'" in the REPL and it will change.

it's not the same though—In Lisp, when you compile your program, a Lisp run-time is attached to it so you can either run the program normally (like any binary) or you could REPL into the program and see what the values of variables are (these values were set at compile time). This is helpful when you have a large dataset you don't want to load over and over.

Re: PEP 762 – REPL-acing the default REPL

#26
post #12

I don't see the point. People who want Jupyter or an IDE know where to find it. Other people who want the basic REPL and mostly use editors anyway are annoyed. Well, perhaps the usual suspects can get another infoworld self-promotion article out of it.

From my experience working with the default repl in e.g. a docker container is extremely frustrating comparing to ipython, and I don't want to be installing ipython and its multitude of dependencies everywhere

Re: PEP 762 – REPL-acing the default REPL

#27

I want a Lisp-like REPL for my Python programs that is available to the user who runs my compiled Python program (so, I want compilation as well). The user will be able to interact with my program (instead of just running the main function), change function definitions, etc. and mold the program to their specific use case while it's running.

Go with Smalltalk instead. Not only do you get REPL-level interactivity[1], user actions are also automatically persisted, and it works with a GUI by default! With Glamorous Toolkit (a Pharo Smalltalk-based IDE) you even get good interop with Python out of the box. Really, if you have users who would benefit from being able to interact with your code directly, Smalltalk is THE way to go :) Ofc, the problem is finding such users in the first place...

[1] As Smalltalk is most often used with GUIs, you don't get a "REPL" by default - instead, anywhere you can enter text, you can right-click and execute that text as code. You can code a real REPL yourself if you want - 10 lines in the "on new line character" method in a generic text field and you're done.

Re: PEP 762 – REPL-acing the default REPL

#28

Earlier quoted context omitted.

they did acknowledge some alternatives, but I agree more discussion would have been nice. FTA - Option 3: Using other existing REPL implementations: The authors looked at several alternatives like IPython, bpython, ptpython, and xonsh. While all the above are impressive projects, in the end PyREPL was chosen for its combination of maturity, feature set, and lack of additional dependencies. Another key factor was the…

IPython is huge: 15,5 Mo without any extras. Python is 150mo. Hard to justify that 10% of the lines of code, source of bugs and maintenance only go to the shell.

I am curious about your suffixes.

I mean, I understand the post fine, but I have never seen the units (Mo, mo) before and am wondering where they came from.

I would guess mo is megabytes(megaoctets?) and Mo is gigabytes(is ipython really 15GB? yikes)

Re: PEP 762 – REPL-acing the default REPL

#29
post #28

Earlier quoted context omitted.

IPython is huge: 15,5 Mo without any extras. Python is 150mo. Hard to justify that 10% of the lines of code, source of bugs and maintenance only go to the shell.

I am curious about your suffixes. I mean, I understand the post fine, but I have never seen the units (Mo, mo) before and am wondering where they came from. I would guess mo is megabytes(megaoctets?) and Mo is gigabytes(is ipython really 15GB? yikes)

Looks like it’s octets: https://en.m.wikipedia.org/wiki/Octet_(computing)

Re: PEP 762 – REPL-acing the default REPL

#30
post #28

Earlier quoted context omitted.

IPython is huge: 15,5 Mo without any extras. Python is 150mo. Hard to justify that 10% of the lines of code, source of bugs and maintenance only go to the shell.

I am curious about your suffixes. I mean, I understand the post fine, but I have never seen the units (Mo, mo) before and am wondering where they came from. I would guess mo is megabytes(megaoctets?) and Mo is gigabytes(is ipython really 15GB? yikes)

I think I remember seeing something about MB=Mo in french, the casing is probably safe to ignore in the gp as ipython is definitely not 15gb
Post reply on HN