Old Man Learns to Code

The riddle goes like this: How many software engineers does it take to screw in a lightbulb ? 💡  The Answer: Zero. It's a Hardware issue. Yuk Yuk. But seriously folk. There is this mass hallucination that software lives in a virtual environment of its own, completely isolated from hardware problems. I just spent hours trying to solve a problem with Python's keyboard .key_read() function . Theoretically, it should capture a single key press and no more. So I had made a function called, wait_4c_key with parameters including (...., , allowed = f' "c" or "SPACE"'). The allowed string is inserted into a prompt telling the user to press one of these keys. The function waits for the user to press one of the allowed keys and returns the name of the key once pressed. So far so good. I used this wait_4c_key() function to pause my program at the end of each printout of a series lesson statements. Never mind what that content was. The pause worked fine for a fi...

 There was the FEAR that somehow my latest functions would not work for a next display frame. That fear was misplaced. The code does as it is told. Not only did the functions work, they accepted f-strings as their string-typed inputs. This meant I could drop ANSI Box Drawing characters in as the filler characters with color !!! The result shown below as the second screen grab: (By the Way, left click on each grab to see it more clearly and in bigger form) Upon hitting the "c" key (no return key needed), the following next learning frame comes up: The second frame looks cool on first glance. However it's got problems. I'm still learning which ANSI Box Draw characters will work best and in what colors. Also, text alignment is still a problem. Note that the last line points out a logic error. For reasons currently not determined, I asked my indented-list-generating function to do lines ending with A-L. But it insisted on doing M as well. What am I talking about? For the ...

 OK. As seen in the below ( click on it to see bigger version ), my program output is almost back to where I started except that "this" output has only yellows and was produced with: (1) the messages being all stored in a messages module, (2) the functions being stored in a separate functions module, (3) other variables being stored in a variables module and (4) with the MAIN Python file calling upon the functions to generate: (A) the "Welcome" mat, (B) a first listing of centered messages, and (C) a second listing of indented messages. The centered and indented messages were produced with just slightly different functions that use getattr().  Haven't gotten all the colors to work though. Don't know why. Maybe call on Pocahontas for help? The idea of using the exec() function didn't pan out. Instead, the GET ATTRIBUTES function a.k.a. getattr(module_name, attribute_name) came to the rescue once again ... TO BE CONTINUED footnote: The last few posts are ...

  Stepping successively through each of my imported-from-Package_01 modules: A, B and C as well as within Main, I inserted test print statements with references to the Ansii dictionary I have stored in module A. The referencing included {v.Ansii['YELLOW'} as well as its shallow copy, {v.yy_}. It worked each time. So basically I am resurrected to the point of having a color-coded welcome mat. The only strange thing is that the string (dot) center(width, fill_char) method is not providing the same per-character width as the lines above and below the middle print-out. (Result screen grab shown next:) Don't yet know why. The WELCOME door mat is generated with 3 function calls, namely, a first line generator that prints the top asterisks (*'s) with the frame ID as a string item (it is not an integer); a second line generator that locates the middle message as having a specific frame type like "intro_" followed by the frame_id (e.g., "00") and further hav...