OMG: That is Python?

General Discussions
#1

Looking at the iRobot Create3 Python examples, led me down an unexpected “That is Python?” adventure. The example used Python syntax I had never seen before:

async def x(): 

r = await x()

showing that I had never explored the Python “standard library” asyncio.

And in reading about asyncio on Real Python I discovered another Python syntax I was totally unready for - type hinting:

async def makerandom(idx: int, threshold: int = 6) -> int:
   ...
   return i

I have at times run into situations where I thought I was putting an integer into a variable only to find that it was a string, or vice versa - I don’t remember exactly but an exception clued me into needing to enforce a cast in that particular situation. Now I see that in recent Python they have introduced “type hints”.

I already knew Python2 was larger than I could learn by osmosis (reading other folks code), but everyday I discover a new something in Python 3.x; Often x is one greater than the version I have installed and thinking I am comfortable with.

So when @Jimrh says:

I can certainly feel his pain and exclaim “That is Python?”

(I should add that the introduction of “closures” caused me to run from JavaScript. I’m still trying to avoid the fact that “Real Python Programers” love lambda.)

2 Likes
#2

The fact that, (at least as I see it), Python is a moving target - things that work in Python “X”, are not guaranteed to work in Python “X+n” or Python “X-n” - makes it a difficult language to do any kind of serious work in.  Not being able to guarantee that, (for example), a robotics routine I write for MY 'bot will work on YOUR 'bot is (IMHO) a major limitation.

It seems to me that Python is “…tossed to and fro and carried about with every wind of doctrine”, (Ephesians 4:14), based on Guido’s “whim of the moment” and whatever hair-brained PIP catches his fancy.

As others have said:
“How do you build on such quicksand?”

2 Likes
#3

There is no language, no operating system, and no robot that will guarantee that! (But perhaps ROS comes closest to enabling “with minimal changes”)

2 Likes
#4

True, but we are operating within certain constraints that make this possible.

For example, it is not only possible, but likely, that a routine written to run on Red Hat 6, (which predates Fedora), will run on the latest RH or Fedora release and may well work on Arch or Debian versions too.

Though Bash ,(and gcc, etc.), have evolved greatly over the years, they are almost strictly backwards compatible.

In many cases the actual source code of a script or system binary of a “standard” command has varied very little from the 1.0 version until now.

Python?
Not so well.  jumping from Python 3.6 to 3.8 or 3.9 is enough to stop you dead in your tracks when an essential feature or library is depreciated with no workable substitution.

That’s head-banging at it’s worst.

1 Like
#5

Python is not the first to grapple with the dynamic needs in programming languages. When Java introduced runtime library versioning, I thought life would be easier. In those days the runtime library only changed about once a year and most applications were published about once a year. Now we have “automatic application updating” and regardless of seeing the “My Q” Garage Door Opener app in the updated list every week for the last two years, they still haven’t managed to allow me to open my garage door from my watch app.

Daily, we disprove Turing’s statement of a programming language only needing three primitives:

  • set
  • test
  • jump
2 Likes
#6

(Along with addition, logical OR, and NOT.)

Every processor’s microcode is based on those functions being built up, like brick and mortar, to whatever edifice you want.

We don’t disprove it, we ignore it by adding fluff to fluff, glitz to glitz, and wrapping the entire thing in a wrapper of useless bling.

2 Likes
#7

If you say so. I have not suffered that in my limited Python use.

2 Likes
#8

Not my experience as a telephony speech recognition / speaker verification applications developer on RedHat. Every release broke something - from DB to I/O to scheduling to windowing - something always needed revisiting “worked before” code.

1 Like
#9

PERSONALLY I have never encountered that either, except during my early attempts to build over Bullseye or Buster 64bit.

However, I have read a great many stories about people who do this stuff every day to make a living, discovering that the clever program or utility they’ve written has just been totally trashed because Guido decided that feature “x” wasn’t important enough to maintain.

The machine code for the 8080 works on everything since then, up to and including the latest i9 gazillion-core behemoth.  Not only does it work, it is guaranteed to work - otherwise the processor chip and MoBo won’t boot.

With a few exceptions, “C” code written by K&R at Bell Labs will compile and run today.

2 Likes
#10

And that was probably because someone upstream, (like gcc), depreciated an essential library without considering the implications.

2 Likes
#11

Really? I find it exciting when I learn that someone encapsulated and thoroughly tested functionality, that I cobbled together across pages and pages of fragile code, allowing the task to be accomplished with a simple import magic ... miracle = magic.performance()

Those folks are the ones pushing the language to be more expressive. Usually the language extensions are not useful to me due to the limitation of my abilities to envision their use.

2 Likes
#12

I have found examples of that too.  Not necessarily within a language, but as an external “magic spell”.

My example for that was implementing a secure context for both data-streams in the remote camera robot project.

Everything I looked at for weeks and weeks and weeks, said it was either impossible or a fuster-cluck requiring code and wrappers more convoluted and complex than a Minoan maze!

Then I discovered nginx.

That beastie is pure magic on the half-shell!  A simple install, finding an “already done that” configuration file I could modify, and within about two hours the Hellespont was turned into a small trickle.

2 Likes
#13

I’m not talking about that.  These extensions and expansions are a necessary evolutionary process.

I am talking more of the kinds of things where they design a motor for large ships and add it to the language, and all of a sudden the oars on my canoe/kayak stop working and I’m left with no way to control my small and fragile craft while I am being swept towards a raging waterfall!

“We have this huge, two-zillion ton MAN diesel now, so we’ll just remove “oars” from the language because they’re obsolete!”
:wink:

2 Likes
#14

And one of the “pythonic” things that drives me to distraction is indentation as a syntactic element.

If I had twenty kopeks, (1 kopek is about 0.01 cent), for every time a rogue space in, (or missing from), a piece of code caused me grief, I’d be loaning money to God Himself.

And if you try to cut-and-paste code from one source to something else?  The Lord Jesus help you - you’re borked!

I have spent more time verifying indentation than I care to admit.

2 Likes
#16

Same for me - I haven’t really run into this.

I like it - makes the code easy to read. And with a decent editor I haven’t had that many problems with this.
/K

1 Like
#17

Agree totally. Since I don’t often use a decent editor, I sometimes annotate with # END loop, # END while, # END if, # END try/except when there are multiple indentations to keep track of.

Even in decent editors though, the vertical hashed indentation level lines can sometime be confusing when there are three and four layers deep with starts and ends on the inner levels.

I get along much better with indentation than with having to end every line with a semi-colon and braces of prior languages I worked in.

2 Likes