Old Man Learns to Code

  The following should be obvious to all. However, for many it's not fully obvious. Here it is: Before we "Learn", we need to know HOW to learn. We need to know the best techniques for imprinting new stuff onto our brain's substrate, for recognizing the imprinted material at a later time and for being able to recall (pull out) the imprinted material on our own without suggestion. A problem though, is that each of us has a strong desire to just " dive right into it ". To immediately jump headfirst into the pool and swim among the intricacies of the Python computer language without concerning ourselves about planning HOW we should "learn". And more importantly, to consider what will cause us to "retain" the learnt material (imprint it into long term memory) and to understand what will enable us to later recognize and further recall at will that material as needed. Dr, Justin Sung has a multitude of YouTube lectures about ...

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...

In our previous episode I had fallen into Circular Import Hell and couldn't find my way out. Many trial attempts and fall backs followed. Now however, the slow climb out of the hell hole is taking shape. I am cleaning out cross-references to modules that have not yet been fully imported. (Circular Hell occurs when the imports are partial rather than complete.) The first aha moment was when I realized I could have each of the successively imported modules (my user-created modules) send me a message, starting with the __init__.py module inside my Package folder doing a print(f"Hi. You have successfully accessed the Package and had it execute your Dunder init code!") Then, as a fist line in my first to-be imported modules: print(f" (1) Initialization of your vars_01 module (holding your shared variables)  has begun"). Then, as a last line in my first to-be imported plural and inter-dependent modules: print(f" (1x) Initialization of your vars_01 module has fini...

 I'd seen rumors of it. Didn't think it could happen to me. Hey, I'm just a beginner/noob Python coder; still not grokking much of it in my nascent and evolving cusp state, Those alleged "circular import" lock ups should happen only to them guru coding experts who are trying to be too clever by a half! Not me. Not yet. (Right?) At first my computer would just freeze up. The cursor stopped moving. I couldn't do anything but shut off the power and boot up again. I worried that PyCharm or Python 3.13.5 had permanently damaged my computer! After many a failed runs and reboots, I managed to move some of the modular code around such that I got a bunch of error messages in the PyCharm console area. It said something about a particular variable not being defined. I looked in my code. Damn it. It is defined. Right there. Very infuriating. Some deep breathes and I re-read the error traceback messages more carefully. Somethingabout this probably being a "circular i...