Open Source Blogs
Immerse yourself in SAP open source! Discover collaborative projects, insights into the latest technologies, and best practices in open source development.
cancel
Showing results for 
Search instead for 
Did you mean: 
JimSpath
Active Contributor
875

Which Python is it? 2? 3? 3.9? 3.11? Hmm. Previously, I wrote about a feature added to Python 3.10 that I found useful given how many other languages offer similar logic symbolisms. I looked across systems I have access to and will relate the spectrum of running versions, or at least installed, and expand beyond Python to related examples.

Languages Evolve

Just as Latin evolved into multiple languages, and English as morphed into dialects that have different spelling, phrases, and pronunciations, computer languages change, at varying rates. For Python, the jump from 2.x to 3.x altered grammar that causes code to fail, in particular the ubiquitous "print" command. In the SAP space, one example I found relates to HANA: hanacleaner.py 

SyntaxError: Missing parentheses in call to 'print'.
 Did you mean print(message)?

Easy fix, if tedious, yet impossible if you can't edit the source.

I learned to program with FORTRAN IV, which succeeded FORTAN II, and was later supplanted by FORTRAN 77. Then, BASIC, which you could purchase built-in to early home computers, evolved into dialects like Visual BASIC, nicknamed VB. And Pascal, where you could simplify your builds with Turbo Pascal.

I don't recall exactly when I learned of Perl, but I do remember the jump from 4 to 5 being dramatic, such that in the meantime no Perl 6 has appeared. The database interfaces developers created (DBD/DBI) gave us a wicked powerful toolset to go against many systems; I probably accessed SAP R/3 without asking permission, since I had direct SQL access anyway as an enterprise DBA. One use was practical extraction/reporting on text files like ABAP stack traces:

# A  ABAP ShmAdm attached (addr=0x7000003e0243000 leng=20955136 end=0x7000003e163f000)

I won't go into significant differences between Perl and Python, just say that when I worked with another volunteer on a shared code base they used Python and I used Perl. We learned from each other.

One lesson I learned was to be specific about the Python version, to avoid uncertainties about which newer syntax or functions might case errors like the one above. They used Emacs, thus getting 2 features for the prices of one. Code examples would begin with:

#!/usr/bin/env python3.11
# -*- mode:python -*-

When we started on that code base in 2013, we used Python 2 ("The env command appeared in 4.4BSD"):

#!/usr/bin/env python2.7
# -*- mode:python -*-

As I documented in the post about the case statement added to Python 3.10, I looked around recently, finding a wide set of Python 3.x installs, though in a newer Windows PC, nothing for 2.x (so likely I can't run my 2013 code now).

Windows Pythons

Just on Windows, I have 2 Python versions for QGIS, another for Scribus, LibreOffice packs another (oh, and Cygwin has Python 3.9.16), and I haven't installed the language directly myself. It gets bundled and is hidden until you search.

QGIS bundled versions:

Python 3.9.18 (heads..., Feb 1 2024, 20:02:10) [MSC v.1929 64 bit (AMD64)] on win32
Python 3.9.5 (tags/v3.9.5..., May 3 2021, 17:27:52) [MSC v.1928 64 bit (AMD64)] on win32

The Python 3.9.5 from 2021 was compiled recently, as it's only one version behind the compiler used for 3.9.18. Apparently, keeping the "major" 3.9 level reduces the risk of plug-ins failing in a domino effect. I have not looked at the recently announced QGIS running on to of QT6; my guess is Python gets bumped up there along with other components.

More embedded versions I found:

Python 3.8.17 (default, Aug 9 2023, 17:36:19) [MSC v.1929 64 bit (AMD64)] on win32
Python 3.11.4 (tags..., Jun 7 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)] on win32
Python 3.7.9 (tags/..., Aug 17 2020, 18:58:18) [MSC v.1900 64 bit (AMD64)] on win32
Python 3.9.16 (main, Mar 8 2023, 22:47:22)

UNIX Pythons

Here I must confess having no access to running SAP systems where Pythons might be hiding. As I was winding down my career in an SAP IT shop, I didn't jump on the HANA bandwagon. But I have UNIX systems at home, and as above, the older installs have the earliest versions. The closest to what might be the OS for a HANA application/database server is OpenSUSE.

ls -ltr /usr/bin/python*
lrwxrwxrwx 1 root root     9 Nov 24 2022 /usr/bin/python2 -> python2.7
lrwxrwxrwx 1 root root     9 Nov 24 2022 /usr/bin/python -> python2.7
-rwxr-xr-x 1 root root 67624 Nov 24 2022 /usr/bin/python2.7
-rwxr-xr-x 1 root root 67624 Dec  9 2022 /usr/bin/python3.8
-rwxr-xr-x 1 root root 67632 Dec 12 2022 /usr/bin/python3.10
lrwxrwxrwx 1 root root    10 Sep  8 2023 /usr/bin/python3 -> python3.11
-rwxr-xr-x 1 root root 67632 Sep  8 2023 /usr/bin/python3.11
/usr/bin/python3.11 --version
Python 3.11.5

On this system, if I only specify "python" on the command line, I'd get 2.7. If I say "python3" I get 3.11.

Other Linux systems (i.e. Raspberry Pi) return similar results, as do FreeBSD and NetBSD. I'll show a Pi5 first, since it's relatively new, has a 64 bit OS, and some compatibility issues with earlier Pi code:

$ python --version
Python 3.11.2
lrwxrwxrwx 1 root root       7 Jan  8 2023 /usr/bin/python -> python3
-rwxr-xr-x 1 root root 6618352 Mar 13 2023 /usr/bin/python3.11
lrwxrwxrwx 1 root root      10 Apr  9 2023 /usr/bin/python3 -> python3.11

Running NetBSD on a Pi (Zero2W) I can also get Python:

python310-3.10.12   < Interpreted, interactive, object-oriented programming language
python311-3.11.4nb1   Interpreted, interactive, object-oriented programming language
<: package is installed but newer version is available
-rwxr-xr-x 1 root wheel 5036 Jan 4 2023 /usr/pkg/bin/python3.10

Not to stray too far off-topic, the above result shows I had grabbed Python 3.10, letting me know I could upgrade to 3.11 with minimal effort. In this application distribution design, newer versions are not automatically/silently added (though dependencies may do so).

Supply Chain Pollution

Here, I refer to the software supply chain, not the global shipping one (but see this SAP community post for an interesting read on the latter). While working as a DBA, I also dealt with infrastructure components such as monitoring and scheduling tools, getting experienced with deploying HP OpenView, BMC Patrol/Enterprise Manager, CA AutoSys, in-house scripting/alerting, and near the end of my time, the infamous SolarWinds (see, e.g., here).

I will highlight the BMC Patrol and BMC Patrol Enterprise Manager (PEM) as another software provider merger/takeover. The Patrol suite had focused on agents and had less of a holistic view; the firm that created the PEM tool used SmallTalk, and built a "state machine" that absorbed messages from multiple sources, then processed them, adding event correlations and issued alerts as configured. Though we were moving from DEC VAX to Alpha on Tru64, the tool was not supported there so we used HP-UX. As a development platform, IBM AIX was supported, and for reasons I ran PEM on that OS also. One advantage of such a split-brain design was keeping our options open in case later releases dropped one or the other. Plus, who doesn't like a challenge like that

When the firm looked for an enterprise scheduler as we moved off of the mainframe to SAP, the team lead said they didn't want to deal with Computer Associates (CA) due to their reputation of buying start-ups and legacy alike, mothballing updates but collecting license fees, so we went with Platinum (which itself had acquired the Autosys owner AutoSystems Corporation. Then Platinum was acquired by CA, negating that logic. And later, CA was gobbled up by global chip-maker Broadcom.

In the monitoring space, I became partial owner of BMC Patrol, setting up dev/prod instances, building out the database, writing alert notification logic, and deploying software agents. In the briefings, the pre-sales engineers were expert at waving away the complexities and risks of autonomous processes, saying they were low impact. What they meant was the agents were efficient, typically consuming little resources. But impact was a different story. Missing alerts could be risky; writing custom code more so unless carefully audited.

I should have known when the SolarWinds support people knew less about many topics than they should, and naming their support community "THWACK" was also a clue (see, e.g. an SAP monitoring question). Though I did some scripting and configuration, I was gone before their software breach was uncovered.

In the Python space, despite having a pretty rigorous language development, testing, and deployment strategy, I heard about "look alike" modules bad actors deployed to trick unwary administrators into creating hidden doorways.

References:

Constant vigilance is the key. I won't pretend to be a security expert: find a good, trustworthy one. Or two, or 3 even, for better coverage.

Since this it the Open Source blog board, I'll mention Zabbix as a monitoring tool. Open-sourced, GNU-licensed, and useful as an alternative to pricey, closed-source tools.

The Faster We Go, The Rounder We Get

This section is inspired by the Grateful Dead song, "That's It for the Other One". When I began programming, the concept of databases and their administration was not like today. Data was stored on cards, or tape, and eventually, disks, with custom code to store and extract results. Not until the PC revolution started and I was introduced to dBASE II at the State Health Department ("Vital Records") did I grasp the power of a standardized data repository combined with software languages. dBASE II was replaced by III, and then by the very widely used dBASE IV. As a testament to that visionary application, the "dot-DBF" file format was used by GIS toolmaker ESRI to encapsulate shape files. The file format is enshrined at the U.S. Library of Congress (LOC): https://www.loc.gov/preservation/digital/formats/fdd/fdd000326.shtml Per the LOC, "dBASE II was available for CP/M, Apple II and DOS in the early 1980s."

With the skill to create tables having columns of the common types such as strings, numbers, and dates, it was an easy step to adapt to databases that supported the Structured Query Language (SQL). The language syntax was designed to be generally portable from one vendors suite to another's, although, as usual, software suppliers vied to keep their customers yoked by adding non-standard features (e.g., Oracle's PL/SQL, a procedural language to perform logic beyond what stock SQL allows).

Along the way, I "skilled up" to be a DBA for Oracle, then MS SQL Server, Sybase, mySQL, and lastly, PostgreSQL, and helped administer/backup/recover systems with DB2, Progress and the Open/LibreOffice HSQL embedded database. I have touched MS-Access systems, and don't count them as databases. SQLite is an outlier that I have used a bit.

QGIS-Python-GNU.png

The DB2 topic deserves a sidebar related to the SAP HANA database support with the Open Source QGIS application. While the post topic is primarily about Python, the language is critical for many features, as are the PostgreSQL client, and for fun, SQLite also.

You might say SAP HANA is one of the "Big Four" supported spatial/PostGIS platforms, as seen in the most recent version I have:

QGIS-databases.png

No DB2! I did a little research into SAP HANA support in the QGIS community, finding an interesting comparison with DB2. Funny, the threads mention SAP a lot but not IBM. Hopefully the current support model won't be "abandon-ware" as has happened with DB2. (let's not see this: "In 2 years, we'll probably have to do the same with the HANA provider.")

Image from a 2019 post by @mkemeter :

Screenshot-2019-11-19-at-16.28.14

 A mere 5 years ago the Big Three were PostgreSQL (named PostGIS here),  MSSQL, and DB2. 

Links:

Credits/thanks for all the fish:

1 Comment
Vitaliy-R
Developer Advocate
Developer Advocate

And I am planning to write a post about Python in SAP Business Application Studio.

Stay tuned 😄 

Top kudoed authors