I feel like there’s a missing discussion as to why they aren’t going with Ipython
replies(7):
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 alignment with PyPy’s implementation.
Python is 150mo. Hard to justify that 10% of the lines of code, source of bugs and maintenance only go to the shell.
Python already has a million libraries built in, adding more in would be a pain. Plus there is the politics of making something "core" when the maintainers aren't part of the core python team.
Given how tight python keeps it's standard library, it seems pretty much imposssible to imagine those kind of advance features being developed while providing the stability that python normally asks from it's standard library.
$ pip show ipython
[...]
Requires: appnope, backcall, decorator, jedi, matplotlib-inline, pexpect, pickleshare, prompt-toolkit, pygments, stack-data, traitletsWell, perhaps the usual suspects can get another infoworld self-promotion article out of it.
In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.
This really seems like a missed opportunity, instead of another repl that will only be used by developers (they even stated that as primary motivation) who can't install anything else, they could have taken a repl that would actually be widely used to integrate into other programs... Instead I suspect pyrepl will eventually experience the same fate as the current repl, i.e. it will languish with no development and get replaced again eventually because it has become to painful to adjust to changes in the rest of the language and changes in terminals.
import time
value = "foo"
def go():
for i in range(10):
print("...", i, value)
time.sleep(3)
import example
import threading
thread = threading.Thread(target=example.go)
thread.start()
[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.
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)
No `vi` mode and not planned. Very modern.
However, now I do feel the need to say this - you really do not need a whole lot to enhance your productivity on the python REPL by a large factor, if you take advantage of some simple built-in facilities:
A. Understand the use of the PYTHONSTARTUP environment variable. This alone is a big advantage. It'll allow you to you automatically import often needed modules and declare helpers that you always seem to need.
B. Once you've gotten used to that, Wrap the built-in module code (or I presume pyrepl) to add the little things that you need and point PYTHONSTARTUP to it
C. Enjoy
At the risk of being downvoted again (not that it matters, so won't delete this time), here again, shameless plug - https://github.com/lonetwin/pythonrc
This pain generates job security for the bigcorp employees and grief for anyone else.
If I'm on the right path with these forum threads, it looks like there were issues with how Debian packages python?
https://forum.freecad.org/viewtopic.php?t=67985
https://github.com/FreeCAD/FreeCAD/pull/6753
https://ffy00.github.io/blog/02-python-debian-and-the-instal...
> ... [Here] are the numpy.distutils features that are not present in setuptools:
* Nested setup.py files
* Fortran build support
* BLAS/LAPACK library support (OpenBLAS, MKL, ATLAS, Netlib LAPACK/BLAS, BLIS, 64-bit ILP interface, etc.)
* Support for a few other scientific libraries, like FFTW and UMFPACK
* Better MinGW support
* Per-compiler build flag customization (e.g. -O3 and SSE2 flags are default)
* a simple user build config system, see site.cfg.example
* SIMD intrinsics support
* Support for the NumPy-specific .src templating format for .c/.h files
try:
# problem
except:
import code
code.interact(local=locals())
This drops you into the interactive shell and you can go wild. Even works inside interactive code like grabbing a live HTTP request or GUI event to see what’s going on.
You'll be happy to know that Python .pyc files, which are created and cached by default, are the equivalent of Java's .class files or C#'s bytecode (which gets embedded inside an .exe wrapper but is still fundamentally not native code).
>The user will be able to... change function definitions, etc.
Of course, this requires recompilation in some form (in Lisp, too - `eval` is not that magic).
That said, if `import`ing your code at the REPL and then calling functions, setting attributes etc. (which has been possible in Python forever) isn't good enough, I really don't understand your use case.
The basic REPL causes serious problems for beginners, and the differences in this REPL are (intentionally or not) largely geared towards fixing those problems. Most notably, beginners can't reliably paste in code examples from tutorials. Either there's a use of `input` which eats the next line of code as interactive input, or a blank line inside a block which the REPL interprets as end-of-code (causing the rest of the block to report `IndentationError`s despite being correctly indented for the intent of the code). They also commonly get tripped up by `help` and `exit` being Python callables rather than REPL commands, and get put off by the lack of built-in screen clearing. (Historically - as it turns out from forum discussion - the Python devs have expected that people actually quit the interpreter with ctrl-D/ctrl-Z, and clear the screen with the terminal emulator's functionality for doing so.)
Yes; it's extremely cruft-filled and nobody wanted to / had the skills to keep the standard library version maintained. There's a note in the Setuptools documentation somewhere about how distutils was deemed fundamentally unfixable, and it doesn't come across like the hacks Setuptools was applying on top of distutils were particularly well understood by anyone.
>In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.
I don't think there's good evidence for this, and the current case is certainly not convincing. Why would they want distutils removed - as opposed to that motivation come from the devs who would otherwise be responsible for its bugs?
I am also very found of pointing out that Powershell still has one of the best ISE's/IDE's in the game for this kind of stuff. One window for editing, a terminal in which whatever you edit runs, and then access to every var/function/etc you just touched in that same terminal is a joyous experience that is shockingly hard to recreate for many languages. Hell half the time I'm just testing out random syntax or a portion of a function and being able to do that in the same session as the script I'm working is awesome.
With enough abuse VS code comes close (for Ruby at least, thank you Pry!) but it would be nice to get a similar experience with Python; I've used a few of the existing REPL options for python, but most of them require you to actually figure out pdb and even then it wasn't as tightly integrated as what I actually wanted.
Didn’t notice your username until you wrote “French”
But I’ve never figured it out and instead have a `requirements-dev.txt` with Jupyter and Ipython in every project because they are so good to have on hand when developing
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).
... Wow, significant portions of that come across to me as AI-generated. I'm pretty sure this is the first time I've gotten that impression from a PEP.
Some examples:
0.01s cpython - with site disabled
0.04s pypy - with site disabled
0.04s cpython - import site and/or built-in modules
0.08s pypy - import site and/or built-in modules
0.13s cpython - import requests
0.31s pypy - import requests
0.31s cpython - import IPython
0.72s pypy - import IPython
1.1s cpython - run ipython nop
2.1s pypy - run ipython nop
Since Python's startup is reasonably fast, it's possible to use it for interactive tools even with heavy imports by spawning a daemon the first time, and just forwarding the requests over a socket. This is mildly annoying but not particularly difficult.
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 using letter keys to move around rather than arrows, as if it takes significant effort to slide you hand 6 inches. You do it often enough and you can go back and forth without even looking.
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 defined protocol for what happens when a class is redefined. Every single object belonging to the old class gets updated to the new class.So I don't know if community work to de-couple ipython into "essential" and "jupyter-stuff" is any viable, but I'd really consider it before committing to write the same thing (but worse) from scratch.
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.
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.
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).
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...
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.
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.
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.
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.
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).
Also it would be great for a `?` directive to print docstrings please.
It's great hearing it in general, but given the HN community is picky, it feels even better.