Live data from Hacker News

PEP 762 – REPL-acing the default REPL

peps.python.org

81–88 of 88 posts

Re: PEP 762 – REPL-acing the default REPL

#81

Earlier quoted context omitted.

Yeah it is. Vi is ancient and not at all modern or use friendly. Look at that bug report! They're complaining they can't go up to the previous command by pressing ESC k. Instead they have to press.... up. Ye gads.

vi fanatics are a weird bunch. Knowing how to use vi can be useful, but I absolutely cannot fathom how someone can prefer it over an actual IDE as their daily driver for writing code. What's especially disappointing is how often they say things like "I like vi because I can do X" and every time, without fail, X is something any reasonable IDE has been able to do for 10+ years. No idea why they're so fascinated by usi…

> What's especially disappointing is how often they say things like "I like vi because I can do X" and every time, without fail, X is something any reasonable IDE has been able to do for 10+ years.

I’ve been switching between 10 to 20 editors over span of my career. You seriously think I’m going to learn how to do basic things in every special snowflake software because editor X thought it is more ergonomic?

And I’m not even going into limitless possibilities of Vi, those are widely available online.

Re: PEP 762 – REPL-acing the default REPL

#82

> The new REPL released in Python 3.13 aims to provide modern features No `vi` mode and not planned. Very modern. https://github.com/python/cpython/issues/118840

Yeah it is. Vi is ancient and not at all modern or use friendly. Look at that bug report! They're complaining they can't go up to the previous command by pressing ESC k. Instead they have to press.... up. Ye gads.

VSCodeVim has 7 millions installs. VSCodeNeoVim has half a million installs.

IdeaVim has 16 mil installs.

Hate it or like it - Vi is here to stay.

Re: PEP 762 – REPL-acing the default REPL

#83
post #58

Earlier quoted context omitted.

Repl can be attached to a live python process (you don't need to restart anything) https://stackoverflow.com/questions/1395913/how-to-drop-into... You could do it even without cooperation from the python app using approach similar to pyrasite (though it is much easier with cooperation--just add a couple of lines).

That only works where you specified (e.g., line 42 where you invoke `code.interact(local=locals()`). Lisp's approach works anywhere (anytime an exception is raised you're thrown in the REPL).

gc allows to get any [non-leaky] object from anywhere. You can even drop into repl over the network.

Debugger can be started on exception if desired e.g., pytest provides `--pdb` arg. Though repl is different--you don't need to interrupt the app itself while you are inspecting it e.g., async repl can be run in the same thread alongside the rest of the app.

I can't remember a single case there Python's dynamism weren't enough for the task (most of the times it is the opposite--there could be less dynamism).

Re: PEP 762 – REPL-acing the default REPL

#84

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…

I think ptpython would have been a much better choice. It is relatively small with few dependencies, much more feature complete, importantly it can run in windows terminal AFAIK which pyrepl can't at the moment. I suspect it has also seen much more testing because it is much more widely used. This really seems like a missed opportunity, instead of another repl that will only be used by developers (they even stated th…

If I remember correctly, unlike the standard Python interpreter, ptpython does not support the replacement of sys.excepthook by a custom one. I know that I look at seeing if I could have it support friendly-traceback but couldn't.

Re: PEP 762 – REPL-acing the default REPL

#86
post #77
post #61

Earlier quoted context omitted.

I usually just have one terminal window open with the Python REPL, and another open with a text editor. Works fine for me, although admittedly it was slightly more convenient back when `reload` was a builtin. (That's maybe the one thing I miss from 2.x, if I had to pick one. Sure, it doesn't honestly really make sense as a builtin; but it could have been added to `site` or something.)

Are you referring to the builtin `reload` found at `importlib.reload`? [0] I use it all the time in debugging. Works great in conjunction with `breakpoint`s for quick iterations. [0] https://docs.python.org/3/library/importlib.html#importlib.r...

I'm aware it's still available. In Python discourse, "builtin" generally refers to names from the builtin namespace (which is immutable and further out than the global namespace), which are available without an import (even a standard library one), like `int`.

Re: PEP 762 – REPL-acing the default REPL

#87

Earlier quoted context omitted.

yeah sorry mb, french comming out

OT, but I love your newsletter! Didn’t notice your username until you wrote “French”

That's lovely to hear.

It's great hearing it in general, but given the HN community is picky, it feels even better.

Re: PEP 762 – REPL-acing the default REPL

#88
post #61

Earlier quoted context omitted.

I usually just have one terminal window open with the Python REPL, and another open with a text editor. Works fine for me, although admittedly it was slightly more convenient back when `reload` was a builtin. (That's maybe the one thing I miss from 2.x, if I had to pick one. Sure, it doesn't honestly really make sense as a builtin; but it could have been added to `site` or something.)

ptpython is great in this usage

I'll have to check it out! :)
Post reply on HN