7 ms·

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.

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.

influx 2y ago
There's a tremendous power with defaults and with "batteries included".
- rgollert 2y ago
  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.
  - itishappy 2y ago
    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/ https://peps.python.org/pep-0632/
    - cozzyd 2y ago
      The deprecation of distutils caused a ton of havoc for e.g. FreeCAD
      - itishappy 2y ago
        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://forum.freecad.org/viewtopic.php?t=67985 https://github.com/FreeCAD/FreeCAD/pull/6753 https://github.com/FreeCAD/FreeCAD/pull/6753 https://ffy00.github.io/blog/02-python-debian-and-the-install-locations/ https://ffy00.github.io/blog/02-python-debian-and-the-instal...
        cozzyd 2y ago
        I don't know the details, all I know is because of that I can't currently install FreeCAD from Fedora repositories which is super annoying, and IMO not the fault of either Fedora or FreeCAD...
    - tqnwx 2y ago
      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.
      - itishappy 2y ago
        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 https://numpy.org/doc/stable/reference/distutils_status_migration.html https://numpy.org/doc/stable/reference/distutils_status_migr...
        zahlman 2y ago
        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?
        handman 2y ago
        Because the "fork" still relied on the presence of the included distutils.
        zahlman 2y ago
        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.
  - zahlman 2y ago
    >The same people removed distutils 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?
ks2048 2y ago
If Python is going to include a REPL (which I think it should), it might as well include useful features that people expect from a modern REPL. (That being said, I personally always install ipython...)
Numerlor 2y ago
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
- zahlman 2y ago
  I've never actually used these industrial-strength "containers" before, but I had understood that they're supposed to be primarily for deployment, or at least some automated testing step in a big CI system. Why would the REPL come into play for these use cases?
otherme123 2y ago
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.
zahlman 2y ago
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 aren't prepared for an IDE to identify problems that are different from what the runtime chokes on; etc.) 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.)
- handman 2y ago
  [flagged]
  - zahlman 2y ago
    >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 https://stackoverflow.com/questions/2589309 and https://stackoverflow.com/questions/5025920 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 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 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 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.

influx 2y ago

There's a tremendous power with defaults and with "batteries included".

rgollert 2y ago
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.
- itishappy 2y ago
  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/ https://peps.python.org/pep-0632/
  - cozzyd 2y ago
    The deprecation of distutils caused a ton of havoc for e.g. FreeCAD
    - itishappy 2y ago
      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://forum.freecad.org/viewtopic.php?t=67985 https://github.com/FreeCAD/FreeCAD/pull/6753 https://github.com/FreeCAD/FreeCAD/pull/6753 https://ffy00.github.io/blog/02-python-debian-and-the-install-locations/ https://ffy00.github.io/blog/02-python-debian-and-the-instal...
      - cozzyd 2y ago
        I don't know the details, all I know is because of that I can't currently install FreeCAD from Fedora repositories which is super annoying, and IMO not the fault of either Fedora or FreeCAD...
  - tqnwx 2y ago
    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.
    - itishappy 2y ago
      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 https://numpy.org/doc/stable/reference/distutils_status_migration.html https://numpy.org/doc/stable/reference/distutils_status_migr...
      - zahlman 2y ago
        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?
        handman 2y ago
        Because the "fork" still relied on the presence of the included distutils.
        zahlman 2y ago
        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.
- zahlman 2y ago
  >The same people removed distutils 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?

ks2048 2y ago

If Python is going to include a REPL (which I think it should), it might as well include useful features that people expect from a modern REPL. (That being said, I personally always install ipython...)

Numerlor 2y ago

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

zahlman 2y ago
I've never actually used these industrial-strength "containers" before, but I had understood that they're supposed to be primarily for deployment, or at least some automated testing step in a big CI system. Why would the REPL come into play for these use cases?

otherme123 2y ago

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.

zahlman 2y ago

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 aren't prepared for an IDE to identify problems that are different from what the runtime chokes on; etc.) 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.)

handman 2y ago
[flagged]
- zahlman 2y ago
  >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 https://stackoverflow.com/questions/2589309 and https://stackoverflow.com/questions/5025920 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 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 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 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.