Why I'm getting REALLY ANNOYED with Python

[jimrh]

Thinking about all the trouble both I and others have had with our robots, one thing comes to mind:

It seems that a large part of the problem is Python.

The big problem with Python is that it’s a “moving target”.  Python code that was perfectly acceptable last week might end up absolutely depreciated and useless next week.

Even now, I confront situations where the difference between Python 7 and Python 9 prevents me from running this utility there, or that utility here.

Now “virtual environments” are virtually mandatory, requiring silly and humiliating options like --yes-i'm-a-damn-fool-idiot-and-i'll-bork-my-machine in order to bypass the mandate.

As I recall, Python was originally designed to be a teaching language, designed to help people ease into modern programming.

But now, if I were a high school teacher or a college professor, I’d think three or four times about teaching Python.  Why?  Because the Python(x) I teach to freshman students today probably won’t even work when they’re seniors or when they graduate and look for jobs.

By comparison, languages like Java or C++ remain relevant year after year, and programs written tens and twenties of years ago still compile and run today.

In fact, (as I remember), one of the hard requirements for ANSI C++ was that it compile and run “old school” ANSI C.  You know, the language created in the '60s on ASR-33 teletypes, at Bell Labs in NJ by Kernighan and Ritchie?  Yes, that “C” language.  It still works and is still relevant today.

By comparison, Python code that works today isn’t guaranteed to run six months from now.

Maybe what we need is a good, old-fashioned FORTRAN compiler?

Or, punt Python and go back to C/C++?

What say ye?

[jimrh]

@jimrh

Because the Python(x) I teach to freshman students today probably won’t even work when they’re seniors or when they graduate and look for jobs.

Or, by the end of the semester?

I get it.

Deciding to depreciate code written for the Altair 8800 running a Z80 isn’t unreasonable.  Depreciating x86 code in certain situations isn’t unreasonable either as 32 bit PC based systems are few and far-between.

However, there are still large volumes of Python 2.n code out there that has little to zero chance of being updated to Python 3.n.  And even if we DO update to 3.n, the question becomes WHICH “n”? 3.7 is already dead meat as far as many utilities are concerned, and God Himself only knows how long the current “n” will last.

Should any company with half the brains God gave a squirrel spend money migrating to such a moving target?  By the time they get it done, tested, qualified, and ready for release - it’s obsolete!

Say you or I decide to migrate all the GoPiGo 2.n code to 3.n - where do we start?  The current Python available for Buster is, (AFAIK), 3.7.  But even that doesn’t cut it as many of the new utilities needed for things like the PiCamera V3 mandate Python 3.9 as a minimum!

So!

We try to migrate EVERYTHING to the latest-and-greatest Python.  That will be guaranteed to break 99% of what’s already working with half the stuff needed not working on later Python revisions and the other half not even EXISTING in later revisions of Python!

If I were doing this, (and if I had the skills to do it), I would seriously consider migrating all the GoPiGo and EasyGoPiGo libraries to native C/C++ libraries that have no dependencies on ANYTHING ELSE and create simple, version agnostic interfaces to it from whatever Python version exists.

This way Guido, the Reigning God of Python, and his minions can do whatever they damn well please and the rest of us don’t care.

In other words, the only way to deal with the Python quandary, (again IMHO), is to ditch Python altogether.  That would have the valuable side-effect of making things easier for the ROS folks too.

Unfortunately, that’s not a trivial undertaking.

What say ye?

[cyclicalobsessive]

@jimrh

The big problem with Python is that it’s a “moving target”. Python code that was perfectly acceptable last week might end up absolutely depreciated and useless next week.

This is not just Python - it is the nature of software. Hardware changes more slowly; Software changes and the changes are often pushed down to us, or come along with a change we do ask for:

• the myriad of user installable applications that cannot be tested together
• the languages,
• the myriad of separately sourced, layers of packages that many people think of as “the operating system”,
• the operating system kernels,

The advantages of “open source software” versus a closed shop like Apple operating systems, with the disadvantage of “too many cooks spoil the soup”…(only one “Cook” at Apple these days)

We once lived with software updates on a yearly basis. Now there are nightly updates on every device around us, and every update is a potential for another incompatibility / “issue” that must first be seen by someone that knows how, and to whom, to report an issue.

Additionally, stability and backward-compatibility limited the number and extent of changes allowed with an update. Now with “Continuous Integration” as the software process d’jour that emphasizes the market advantages of “world changing features”, our world is now regularly rocked by “world stopping issues”.

The Python push for virtual environments is a mirror of the business push for “containers” like Java virtual machines and Dockerized applications - they strive to eliminate multi-application interactions, and prevent unauthorized changes. Sounds good to a consumer, but the reality for developers is a nightmare.

@jimrh

I would seriously consider migrating all the GoPiGo and EasyGoPiGo libraries to native C/C++ libraries that have no dependencies on ANYTHING ELSE and create simple, version agnostic interfaces to it from whatever Python version exists.

In fact, that was my original approach for GoPiGo3 on PiOS Bookworm on Pi5, since the Python GoPiGo3 API was broken but the C++ API appeared to work. Then I found that there is no easygopigo3 in C++, no mutex protected I2C in C++, no 16-tick encoder support in C++, and gee, if I just commented about 10 lines in gopigo3.py I could use Python with no loss of functionality!

There is one more Python “Gotcha” that you have not mentioned - the **GIANT ELEPHANT IN THE ROOM ** - the Global Interpreter Lock. The virtual environment change is nothing compared with the discussions of a Python 3.12 option to disable the GIL.

PEP 703: Making the Global Interpreter Lock Optional (3.12 updates) - PEPs - Discussions on Python.org.

@jimrh

the only way to deal with the Python quandary, (again IMHO), is to ditch Python altogether. That would have the valuable side-effect of making things easier for the ROS folks too.

Indeed, “Real ROS Programmers Use C++” but the historical approachability of Python for noobs keeps ROS development in Python a near neck-in-neck option in the ROS community.

I recently complained that, for years, the ROS tutorial code in Python have treated control-c as an unhandled error while the C++ tutorial code cleanly exits. The ROS 2 Jazzy release team started their answer with “That is the nature of Python, but perhaps we should relook at the Python examples to see about that.” Python developers are often “second-class citizens” in the community.

@jimrh

Unfortunately, that’s not a trivial undertaking.

I have to hand it to Dexter for including basic C, Csharp, Go, Java, NodeJS, Scratch, and Python GoPiGo3 API, considering each has a different development model and programming style. As an educational robot, Python has the broadest functionality and most complete set of example programs.

I often wonder what my robots would be if I had chosen the Turtlebot3 instead of the GoPiGo3 in 2016. The GoPiGo3 API was much more approachable than requiring ROS at the time, so I loved doing tiny Python programs that used only the DI API. ROS has always had too-many-cooks, which is harder that I want to understand everything going on in my robot’s brain.

Robots are not easy. Software is not easy. But at least we have an easy place to discuss the difficulties.

[cyclicalobsessive]

@jimrh

Say you or I decide to migrate all the GoPiGo 2.n code to 3.n - where do we start?

All the GoPiGo API code is already Python3 compatible.

I don’t know if the GoPiGo3 GUI utilities are Python3 compatible, but I suspect they are already Python3 compatible but not Wayland window manager compatible.

And we know the GoPiGo3 install/update script was made Python3 compatible, but has numerous OS incompatibilities.

The biggest change I made four years ago to move all my code from Python2.7 to Python3.x was actually not part of the language, it was only for convenience:

I changed the bash directive from:

#!/usr/bin/python
or
#!/usr/bin/env python

to:

#!/usr/bin/python3
or
#!/usr/bin/env python3

since I never used python xyz.py. I always make my programs executable and invoke them with ./xyz.py

As for the print() and division, I followed the DI practice of including the future clauses and wrote to the Python3 standard from the beginning.

The single Python2 to 3 change that hit me was obsoleting xrange() to range().

There was a tool to convert code to Python2 to Python3, but I never bothered with it.

The continual Raspbian/PiOS changes and continual Raspberry Pi hardware changes have been mixed blessings with the curse of constant incompatible libraries.

[jimrh]

@cyclicalobsessive

@jimrh

The big problem with Python is that it’s a “moving target”. Python code that was perfectly acceptable last week might end up absolutely depreciated and useless next week.

This is not just Python - it is the nature of software. Hardware changes more slowly; Software changes and the changes are often pushed down to us, or come along with a change we do ask for

Not to mention the problems caused by being located in a “sanctioned” environment!

In order for me to get access to libraries, code, examples, etc. - I need to visit sites like Adafruit, et. al.  However, when I try to go there I get a web page with a BIG RED “X” and the statement YOU HAVE BEEN BLOCKED! (cloudflare xxxxxx) and I am just plain-‘ole outta’ luck.

 

So, the obvious way to solve this problem is to install a VPN.  Except for one teeny tiny problem.

The VPN provider web sites where you download the software and copy your credentials are also blocked by Cloudflare!

 

In other words, you need a VPN in order to install a VPN. 

Sheesh!

It’s doable, but it’s a left-handed, Rube Goldberg, McGivvered ball of GAGH! in order to accomplish it. . .  However the fact that you can cut-and-paste from the host system to a Real VNC Player window is quite helpful.  And it turns out that NordVPN has a world-readable repository that you can install from, IF you can find the links to it.