[TriLUG] Broad question

Steve Litt via TriLUG trilug at trilug.org
Sun Sep 3 03:42:53 EDT 2023


Stephen P. Schaefer via TriLUG said on Sat, 02 Sep 2023 21:53:05 -0400

>My experience with Python is that its ecosystem introduces breaking
>changes every half dozen years or so, whereas perl 5 code from the
>1990s just works.  Maybe I just got lucky with the perl modules I
>experienced.  As for readability, I tried finding a bug in the Red
>Hat/CentOS subscription-manager python code once (wasn't accepting our
>internal certificate authority when communicating with Foreman (if it
>had been Satellite it would have been Red Hat's problem)), and I was
>not enthused.   Python's churn may be good for keeping one
>employed.....

Python got a real black eye in the Py2 to Py3 switch, and I think the
black eye was undeserved. First of all, the changes that broke things
were minor, mostly related to print changing from a statement to a
function, which in my opinion is much better. There were some problems
with non-English UTF-8, because Python2 handled it wrong (UTF-8 was
bolted onto 2.x hence done the wrong way). People issued workarounds to
make Python 2.x do UTF-8 correctly, and Python 3 broke those
workarounds. If the original incorporation of those workarounds were
done in a sane manner, they could easily be found and changed.

Second, they started deprecating Python in 2006 anticipating an end
date of 2015. Most developers didn't have the guts to port their
applications in the *9 years* alotted, so then they extended the end
date to 2020. Considering how little work was required to change a
Python2 to Python3 file, I think this is plenty of time. People just
didn't switch until the bitter end. Developers could have easily
switched years earlier.

Third, by importing things from __future__ in Python2, they could make
much of their Python2 Python3 compatible once they made it __future__
compatible.

As far as ability to run 1990's applications, that's nice, but heaven
help Developer B if he must add features to Developer A's Perl code,
because, with the "Many ways to do it" philosophy, I've seen Perl I
couldn't tell was Perl. I'd rather rewrite in Python 3 than trying to
make extensive changes in somebody else's Perl.

And of course, as mentioned, Python's wonderful standard library and
other packages mean anything you start in Python you can finish in
Python.

CPAN? Around 2023 I had to do a CPAN update to accomodate some awful
Perl based shopping application. The update broke Vim. Yeah, I know
it's supposedly imposssible for that to happen, but it did. I had to
bring in a Perl Guru to fix Vim, and even he couldn't get that shopping
cart app to add the features wanted by the client.

And don't get me started about Perl 6, oops, I mean Raku. Announced in
July 2000, it was incompatible with a lot of Perl 5 code. It took
several years from then to get a working implementation, and by that
time the world had moved on to Python, Ruby and Lua.

Unless the world experiences a technological change as deep and broad
as ASCII to UTF-8, I doubt any future Python 4, if Python 4 even
happens, will break much Python 3 code.

SteveT


More information about the TriLUG mailing list