Refactoring Pygrr: the big rewrite!

Up until the 3rd August, 2021, Pygrr's code was contained in a single file, making it a "module". Well, that's not so good for maintainability, as there was so much going on in the same place. To make matters worse: there was no documentation for the file (bits of text that explain what each class or file does - for human benefit), and practically no code comments (small lines that explain what a bit of code does - for human benefit).

I could very easily take a break for a few months, come back, and have no idea what the code was doing, causing me to have to restart. Not only that though, as the alpha date looms ever-close, the prospect of Pygrr opening up open-source becomes, too, ever-close!

Now, I really don't want to show everyone the code with it being a horrible mess, that's like visiting a home-designer's house and it being a dump! So, I started to do something about that.

Python has an in-built "import" command, which allows you to include other modules, packages and files into your code. This means that it basically takes the code, and adds it to your file, metaphorically speaking!

So, I began a rewrite then, and I've been hard at work since. That explains the lack of posts, and, for those of you subscribed, the lack of newsletters.

So, let's split Pygrr and Pygrr PolyArt into packages, with sub-package folders inside them!

You'll see some common recurrences here, notably the file "__init__.py". Well, .py is the file extension for a Python script, but __init__? That's a default Python method, which is opened upon instantiation.

Jargon free, basically, when that package is imported, all of the code in __init__ is run - allowing us to import further files and run code. 

With the amount of .py files now, the prospect of users opening one of the files individually occurs, which would just throw an error, as they're meant to be imported as a package - so, let's do something funny to fix it!

So, the vision is as follows:

The file should detect when it is not being imported;
The file should tell the user what the file is meant to be used for;
The file should tell the user it shouldn't be ran - in a fun way;
The file should close.

So, Python has ways of doing the first two - Google "docstrings in python", and "__name__ in python". The last one is easy, just run the command quit().

And for the only one remaining? I'm going to give the file sentience...

 "oooooooooooh" - I hear you all say...

Well, not really, it should just greet the user with a custom message... So, I whipped up a quick module that gave the desired output, called it "sysmessages", and plugged it into every file. Don't worry, each message isn't hard coded, it takes them from a text file containing each message, for easy changeability!

Here's how it looks if I run, say, _canvas.py...

As you can see, it first prints out the documentational description of the file, and then says something. When the user presses enter, it will quit!

That's weird, you weren't meant to run me...

Hi! I'm not sure how you got here, but, oh well!

Wrong file buddy!

Hey... I'm not supposed to be ran!

I'm alive! Hang on, oh, oops, gotta go!

Ay, you found me!

Don't let me catch you running this file again, buckaroo...

These are all (currently) of the messages it can choose from. Anyways;

Isaac, over and out...

Popular posts from this blog

Messing around with procedural art - Turtle graphics

Blog post #0 - Hello, world!

The fossils of Morocco | Mosasaurus beaugei