Hacker News new | ask | show | jobs
by mikl 668 days ago
> Stop breaking my builds.

You don’t have to install the latest version if you don’t want to. If you use a version manager, you can keep using whatever version you want for many years.

1 comments

The value of Python is its ubiquity. That disappears if you have to make sure to install old Python versions because the system Python got updated and the update broke something.
most tutorials I'm aware of actively discourage use of the system python version for this very case.

i don't think it's too surprising that versions differ. there are good tools to manage the python version used -- i personally like pyenv.

This is the exact problem I have. No bash scripting tutorial would tell you to not use your system bash. No perl tutorial would tell you to avoid your system perl. No C tutorial would discourage using your system's gcc or clang.

As I said, a lot of the value I see in python is in its ubiquity. This disappears if you can't use the system python.

You can always use the system python to create a venv. It's ubiquitous in the sense that you don't need root access to use properly, not that it comes set-up and ready to use for all purposes.
Hopefully no complaints when you break something in system python and your system has a negative reaction to that breakage.
I don't understand this comment.
There's the risk of breaking the system when using system python. Install some dependency for your script that changes something that a core service is depending on in an unexpected way can lead to hours of tracking down the issue. Or a full reinstall in the extreme. That's why users are to avoid using system python.

But if you value that ubiquity more than your sanity, I hope you find and fix any breakage yourself and not pester other devs for support.

You can just use rye and retain your sanity like everyone else.
As I said, a lot of the value I see in python is in its ubiquity. I don't understand why I need to keep repeating this.
>>The value of Python is its ubiquity.

+1

Most Python use case today is some what on the similar lines as Perl. Having a stable large install base. Availability of libraries, backwards compatibility, performance matter way more than more features at this point.

There is no new replacement language in sight, so Im guessing we will be using Python for long into the coming future.

I also hope Python had something on the lines similar to CPAN. We are decades into the journey, and Perl still shines like the Sun in this regard.

Part of me feels sad Perl 5 didn't go the way Python 3 did.

Python 2 -> 3 transition is probably considerable part of why it's becoming less ubiquitous.

Especially considering how a major distro[1] that defaulted to Python 2.7 only just was dropped by many[2] - but not all, because some "heroes" jumped at the last moment to provide binary compatible support options

[1] CentOS 7

[2] Especially if you wanted to be in any case acceptable to sell to FedRAMP-requiring or similar clientele, but in Europe NIS 1 (already in force) and NIS2 (starts enforcement this year) ban software that is post end-of-support

Python 2 -> 3 transition is probably considerable part of why it's becoming less ubiquitous.

What do you mean? I've been using python since 1.5 and it is more ubiquitous today than it has ever been at any other time in the past.

BLUF: It's definitely more ubiquitous in terms of general use, but I find it becomes less ubiquitous as in "always available on a Linux system" and increasingly painful.

I remember Python around 2.2 becoming ubiquitous and "obvious" option as "better than perl and also certainly available". Python people would even trash talk other communities for not being able to "just download the libraries from distro repo" or needing specific versions whereas you at worst grabbed updated python for your distro.

(The following is a somewhat chronological rant)

Fast forward few years and me getting out of university which for various reasons was (apparently blissfully) Python free. In between we get through the "huge"transition from Ruby 1.8 to 1.9/2.0 (had to help professor update coursework even).

The 2->3 transition interrupted that, and I am suddenly facing that a) python3 actually got released b) despite several years, it's not even guaranteed default c) you now have to explicitly use python3 or python3 in shebangs because you don't know what version of python is default d) virtualenv wtf e) there's still new code being written depending on py2 f) the library situation can be a maze.

Since I mainly worked as "DevOps" person, not a python programmer, I get to deal with increasingly borked python deployments. Suddenly authors names in comments cause deployments to fail on servers but work on dev machines as well as mine. Took long to figure, the same code working when connecting over SSH vs not working when started by systemd shows it's python deciding encoding by locale and barfing on 8bit characters (including utf-8).

Virtualenv, increasingly necessary multiple python versions, all driving increasing replacement of python in admin/management tooling. Chef and Puppet (finally) laughing from their omnibus setups at ansible exploding depending on what python is default on target distro and people who pushed ansible confused because "it only uses SSH, there's no agent". Even more movement to Golang because of static binaries.

Virtualenv becomes the effective default, forget about installing packages through distro (subjective take, I know, this is a vibe I know it's still possible).

Python 2 goes EOL and out of support but it's still default on distros used by paying customers (this changes - but not fully - this year on June 30th... Thanks to government regulation - thanks Obama /s)

I now mostly see python deployed with not just batteries but the whole jungle included (Docker). If it's s good container it doesn't have a complete copy of development environment.

Increasing mess with packaging. Distros reducing python dependencies, system python increasingly seems mostly for use only by OS components. Python equivalents of rbenv/rvm increasingly suggested as "right tool". Package build items exploding because transitive rust deps.

Customers sometimes demanding OS installs without Python. Increasingly encountering distros with no python at all.

Python packaging still feels worse today than rubygems were a decade ago.

Finally increasingly suggesting to prospective projects that benefit/cost of python goes below 1.

I used to love python back in 2002-2006 timeframe. Rails making it so damn easy to handle some projects and finally starting to grow Lisp (thanks to a detour through Haskell due to XMonad) made me look away. Even "ML ecosystem" mostly gives me more reasons to rant against Python (Tensorflow packaging as PIP wheel makes me problems even when I am going to use Python.

So, yeah, lots of code in Python, ubiquitous python jobs. Retreat from "write your tool in python, it will be easy to distribute, every distro effectively preinstalls python unless it's some LFS or Slackware weirdo"