Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 762 – REPL-acing the default REPL

peps.python.org

Post reply on HN
Print view View original

71–80 of 88 posts

Re: PEP 762 – REPL-acing the default REPL

#71

Post by zahlman »

handman wrote: post #66
zahlman wrote: post #49

Earlier quoted context omitted.

They really don't. The Python userbase has a very high percentage of beginners at any time, and trying to move them into Jupyter or an IDE before they understand fundamentals, usually just makes it much harder to help them with programming problems (because they don't know what's language functionality and what comes from their tools; they don't know anything about the virtual environment the tool is managing; they a…

[flagged]

>No one had issues beyond the small annoyances

The "small annoyances" are only small to you because you have spent at least a few days on this.

Countless questions on Stack Overflow that were caused by these problems, but closed because experts couldn't reproduce the problem and/or beginners couldn't describe it clearly, beg to differ. I've encountered scores of them myself and always despaired at not having a proper canonical to route them to. Some of the better attempts include https://stackoverflow.com/questions/2589309 and https://stackoverflow.com/questions/5025920.

For that matter, an analogous issue with IPython (so it clearly doesn't fix everything) resulted in https://stackoverflow.com/questions/43189302, which has almost a million views. And then there's the problem in Visual Studio Code whereby command-line Python invocations end up dumped into the Python REPL that VSC opens: https://stackoverflow.com/questions/51540391 .

>and you could use the included IDLE anyway.

My experience with IDLE was that, because it was implemented using Tkinter, it would cause all sorts of subtle threading issues when I tried to develop Tkinter programs with it. Its REPL also edits text the same way as a text editing window - so there's no nice keyboard shortcut for command history, and you can put the insertion point in places that aren't the current prompt. (With current versions, this appears to just disable typing temporarily, and also the `>>>` prompts get a separate column. My recollection is that it used to be considerably less pleasant.)

But sure, pasting works properly. It also doesn't let you deliberately type an empty block (invalid syntax; see https://stackoverflow.com/questions/1528903), unless you deliberately delete the automatically inserted whitespace. (The traditional REPL couldn't insert that whitespace because it would mess up copy-paste even more.)

>the same people who are used and incited by the Python ruling class to flag posts and report people on discuss.python.org

They aren't doing it because of beginners' hypothetical "needs". They're doing it because of beginners' hypothetical feelings. How they expect people to phrase themselves, or what proactive gestures they might expect towards "inclusivity", have absolutely nothing to do with their ideas about what mistakes beginners commonly make or what mindset is leading them there.

I am, by my reckoning, currently about the third-last person on the planet you should be engaging with this line of rhetoric (after Tim Peters and David Mertz - I don't know enough about Steve Holden to say). I lived the situation you're appealing to - and I'm also still reading discuss.python.org even though I can't post there, along with curating Stack Overflow, posting on Codidact etc. I also (though I don't usually talk about it) used to moderate the r/learnpython subreddit. It's very easy for experienced programmers to lose sight of the actual needs of beginners. But I'm doing everything I can to be more aware.

Re: PEP 762 – REPL-acing the default REPL

#72

Post by zahlman »

handman wrote: post #67
zahlman wrote: post #50

Earlier quoted context omitted.

I never did understand this. It appears that they were maintaining their own fork of distutils anyway (and if you open up a latest-version wheel today you should still see it included); so why did the standard library removal cause a problem?

Because the "fork" still relied on the presence of the included distutils.

But it's open source. Couldn't they just vendor it? Not like that would noticeably bloat a wheel that's already close to 20 MB on some platforms.

Re: PEP 762 – REPL-acing the default REPL

#73

Post by krick »

HellsMaddy wrote: post #41
wiseowise wrote: post #36

> 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

Honestly, even as a neovim user, I don’t find vi mode to be very ergonomic for interactive prompts, and I prefer emacs-style keybindings in these cases. The only time I feel the need for vi mode is when I want to copy something, but in that case I already have that capability through tmux copy-mode. I would prefer if the team prioritizes python-specific functionality first and foremost.

Me too, but I actually think the complaint is totally valid. I mean, somebody does use it, and it isn't some horribly obscure feature, it's built into most terminals, it's pretty much standard Linux functionality at this point, and old REPL does support it, so when you introduce new default REPL, but then say "uh, no, we don't use that shit you use, so fuck off and use the old REPL, loser" it's not very nice. (And even if they didn't outright call him a loser in that thread, it's still not very nice.)

In short, the fact you, me and these guys don't understand why anybody used vi-mode doesn't mean shit. It came before us, apparently still exists, and well may outlive your neovim and PyREPL. Prioritizing other stuff is one thing, dismissing and closing the issue because "nobody (i.e., me) needs that shit" is another.

Re: PEP 762 – REPL-acing the default REPL

#74

Post by behnamoh »

ks2048 wrote: post #69
handman wrote: post #68

Earlier quoted context omitted.

This is nothing like the Lisp debugger. It is very hard to convince Pythonistas of the fact: https://news.ycombinator.com/item?id=36888648

Interesting thread. I only read some of it, but I did find one answer that tells me how Python and LISP differ: As an example, I suppose that when you’re developing code in Python’s pseudo-REPL you often reimport a file containing class definitions. When you do that, what happens to all the old objects with the old class definition? Nothing, they still belong to the old class. ... In Lisp, it’s different. There is a…

> In Lisp, it’s different. There is a defined protocol for what happens when a class is redefined. Every single object belonging to the old class gets updated to the new class.

This. Lisp gives you ultimate power but of course, it means it unlocks more ways to shoot yourself in the foot in the process. Most organizations don't want "smart hacky" solution (i.e., they don't want you as the programmer to fix issues in creative ways that Lisp provides to you), instead, they want "standard processes" that can be taught to new hires (i.e., they want you as the programmer to write standard, idiomatic code that everyone understands). The latter comes at the cost of less flexibility (i.e., when your rock solid code crashes, it means you must update the source code instead of fixing it on the go like in Lisp restarts).

Re: PEP 762 – REPL-acing the default REPL

#75

Post by behnamoh »

Nab443 wrote: post #22
behnamoh wrote: post #11

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.

Last I heard it was moving too fast and broke a bunch of stuff.

Re: PEP 762 – REPL-acing the default REPL

#76

Post by behnamoh »

d0mine wrote: post #58
behnamoh wrote: post #25

Earlier quoted context omitted.

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.

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).

Re: PEP 762 – REPL-acing the default REPL

#77

Post by PyWoody »

zahlman wrote: post #61
AcerbicZero wrote: post #53

I have been "advocating" (i.e. complaining) for better REPLs basically the entire time I've been writing code - One of my favorite pasttimes is getting all flustered and trying to throw enough extensions and custom code to get an offline REPL.it style experience out of VS Code for whatever language I'm playing with at the moment, and lately its kinda been working (for Ruby, at least). I am also very found of pointing…

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...

Re: PEP 762 – REPL-acing the default REPL

#78

Post by kamaal »

Sohcahtoa82 wrote: post #64
IshKebab wrote: post #44

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…

>>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.

Given Python has to be installed every where. A light weight editor like vi is the best choice for editing on servers.

To that extent it might not be a full fledged IDE but is perfect for what it is designed to do.

Re: PEP 762 – REPL-acing the default REPL

#79

Post by kamaal »

handman wrote: post #66
zahlman wrote: post #49

Earlier quoted context omitted.

They really don't. The Python userbase has a very high percentage of beginners at any time, and trying to move them into Jupyter or an IDE before they understand fundamentals, usually just makes it much harder to help them with programming problems (because they don't know what's language functionality and what comes from their tools; they don't know anything about the virtual environment the tool is managing; they a…

[flagged]

>>How did beginners survive the previous REPL for 30 years?

Mostly by not using it at all.

REPL doesn't maintain a state, atleast not complex enough state to be relevant to most things. People only use it for hello world kind of demo and don't touch it ever again.

Re: PEP 762 – REPL-acing the default REPL

#80

Post by kazinator »

ks2048 wrote: post #69
handman wrote: post #68

Earlier quoted context omitted.

This is nothing like the Lisp debugger. It is very hard to convince Pythonistas of the fact: https://news.ycombinator.com/item?id=36888648

Interesting thread. I only read some of it, but I did find one answer that tells me how Python and LISP differ: As an example, I suppose that when you’re developing code in Python’s pseudo-REPL you often reimport a file containing class definitions. When you do that, what happens to all the old objects with the old class definition? Nothing, they still belong to the old class. ... In Lisp, it’s different. There is a…

This protocol is in Common Lisp. Common Lisp is not Lisp. Not every Lisp has CLOS.

Common Lisp is not the be-all end-all in Lisp.

Redefining the classes of objects at run-time is not unilaterally a great idea.

It's not obvious how to implement it in such a way that applications which don't use it don't have to pay any extra cost for the support.

There being a defined protocol for what happens when a class being redefined does not add up to you automatically having an application that can upgrade itself while it is running, from any version to any version, bug free. You have to test and debug all the combinations, or else support only certain combinations, requiring multiple upgrades.

This is something that will add complexity to your upgrade plan.

I can see someone like NASA using such a tool for a very specific scenario, which can be replicated on Earth and tested, and then carried out remotely in some space probing vessel.

Post reply on HN