It's a good start, and please do more... Even small QOL improvements like tab completion for filenames are important and is what makes me to install ipython at this point.
PEP 762 – REPL-acing the default REPL
31–40 of 88 posts
Re: PEP 762 – REPL-acing the default REPL
#32Earlier quoted context omitted.
There's a tremendous power with defaults and with "batteries included".
The same people removed distutils, which is why at my company we had to update several internal C-extensions. In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.
It looks like a lot of care went in to disclosing this and providing replacements. Can I ask what you were using it for?
Re: PEP 762 – REPL-acing the default REPL
#33I 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.
Maaaybe color highlight can annoy some purist, but multiline edit and cursor movement are the bare minimum. Either add these features or get rid of the battery included Repl in favour of third parties.
Re: PEP 762 – REPL-acing the default REPL
#34Earlier 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)
yeah sorry mb, french comming out
Re: PEP 762 – REPL-acing the default REPL
#35Earlier quoted context omitted.
The same people removed distutils, which is why at my company we had to update several internal C-extensions. In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.
It looks like a lot of care went in to disclosing this and providing replacements. Can I ask what you were using it for? https://peps.python.org/pep-0632/
The deprecation of distutils caused a ton of havoc for e.g. FreeCAD
Re: PEP 762 – REPL-acing the default REPL
#36> The new REPL released in Python 3.13 aims to provide modern features
No `vi` mode and not planned. Very modern.
Re: PEP 762 – REPL-acing the default REPL
#37I replied here earlier with my own pet project to essentially say that you don't need a whole lot of complexity to solve for QOL improvements in the console but was promptly downvoted, I thought that was fair and so deleted my comment.
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
Re: PEP 762 – REPL-acing the default REPL
#38Earlier quoted context omitted.
The same people removed distutils, which is why at my company we had to update several internal C-extensions. In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.
It looks like a lot of care went in to disclosing this and providing replacements. Can I ask what you were using it for? https://peps.python.org/pep-0632/
Not the one you are asking, but NumPy literally converted to meson because of the deprecation. There was tons of pain for so many extensions.
This pain generates job security for the bigcorp employees and grief for anyone else.
Re: PEP 762 – REPL-acing the default REPL
#39Earlier quoted context omitted.
It looks like a lot of care went in to disclosing this and providing replacements. Can I ask what you were using it for? https://peps.python.org/pep-0632/
The deprecation of distutils caused a ton of havoc for e.g. FreeCAD
I won't argue with that, but I would like to understand why.
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...
Re: PEP 762 – REPL-acing the default REPL
#40Earlier quoted context omitted.
It looks like a lot of care went in to disclosing this and providing replacements. Can I ask what you were using it for? https://peps.python.org/pep-0632/
Not the one you are asking, but NumPy literally converted to meson because of the deprecation. There was tons of pain for so many extensions. This pain generates job security for the bigcorp employees and grief for anyone else.
Super helpful, thanks! The NumPy page on the migration has some details on the differences:
> ... [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