Hacker News Reader

Comment by ciupicri | Hacker News Reader

Too bad it doesn't come with Python 3.7, only 3.6. Fedora 29 managed to switch to 3.7, although it was released just two weeks ago.

View on HN

Later versions of Python will be supplied as modules. So will Python 2. They are parallel installable with "system-python" which remains at 3.6 for the lifetime of RHEL 8. (Note that in general modules are not parallel installable, but in this one case it is).

As a module will it have as many libraries available as the system Python? For example does it come with scipy packages, twisted, pyserial, xlrd/xlwt/openpyxl, gobject (for GTK+ apps), etc?

AIUI the plan is to build everything for each Python module (plus system-python).

However there are two things that mean it's not quite as good as you would like:

(1) Base RHEL 8 will only have a fairly minimal set of Python packages (indeed, packages in general).

(2) Products on top - things like OpenStack - will settle on a particular Python version (ie. module) and only be built against that version, and will require the corresponding Python module to be enabled.

I'm more surprised by the fact that no Python is installed by default on a Red Hat distribution

https://access.redhat.com/documentation/en-us/red_hat_enterp...

I think Perl and Python were only ever installed by default because there were management utilities (GUI and console) written in them, so they were prerequisites for what was considered a minimal system. RHEL has been pretty good the last few years at paring down the base minimal install to actual essentials. I view getting to the point that Python is not required for a base install an achievement.

Me as well, since someone had the clever idea to create GUI distribution management tools in Python, it is a pain to use them, given how slow some of them are.

It's unlikely Python is to blame for that, unless they implemented something very CPU bound in it. I wrote wxPython apps in 2000 or so and they were very responsive.

Well the previous generations written in C used to perform quite well.

It is likely a combo of Python + someone not good at using Python with networking. When working with anything that talks a lot over networks you need to use threads or separate processes to keep things feeling responsive during network delays. Python doesn't make this easy, so lots of devs skip it and it makes the programs feel sluggish.

Hmm, that might make sense on a server, but this is talking about a GUI client. Also, Python has trouble with CPU-bound threads but not those IO-bound.

A huge amount of work was done to minimize the base set of packages (called "BaseOS"). Including rewriting parts of dnf from Python to C++.

Wasn't python required for YUM to function correctly? Or has DNF been written in something other than python?

yes. https://rpm-software-management.github.io/page4/ (some of the specific posts seem to be unavilable)

Platform python see comment above

Actually there is a default python and it’s called platform python. That one lives on purpose in /usr/libexec however is mainly supposed to be used by platform tooling like dnf/yum etc

Reply on news.ycombinator.com