Tag: Python

What with the excitement going on around #Dungeon23 online, I’ve been referencing various source materials more, such as Filling in the Blanks, the Tome of Adventure Design, and the Hex Flower Cookbook, among many others. Some of these, I want on-hand as a physical product while I’m working; so, I figured to print some out and make little booklets of them to have on-hand. Surprisingly, however, printing in booklet form appears to be a little tricky in Linux!

Now, LibreOffice has a way to print brochures, as they call it, but that involves using LibreOffice Draw to edit a PDF file and not all of my PDFs can be opened with Draw. I’ve found a solution using Adobe Reader but Reader is discontinued on Linux. Reddit offers several solutions, including manually setting the print order, using Boomaga as an intermediate step, and so on. All in all, a little trickier than I figured it would have to be to just print something in booklet form!

In the end, I figured I could just make something myself. Using the advice on manual ordering from Reddit, I ended up making a quick Python script that reorders a PDf file and sends it to the printer with the right settings immediately. It was nice to see I still have enough knowledge to quickly bash together a script to do what I need without much issue. I added a few command-line argument options and made sure that I could expand the script if I ever run into missing options.

For now, it’s time to bind the copy of Filling in the Blanks!

I was reading a Reddit post on how Guido van Rossum stated he wanted to make Python work faster when I came across a comment chain where somebody joked that you can make any program faster by using fewer print() statements. A reply quipped “How else am I supposed to debug my programs?”. I’m assuming it was a joke for them, but this is certainly a weakness on my part. Since I’m self-taught, I find myself using standards that make sense to me, but would be bad practice for a formally taught individual. In this case, that’s using the print() statement to help me debug by running the program and seeing what I end up with, tweaking that, running it again, and so on.

Python programming: We want to make the language twice as fast, says its creator from Python

Fortunately, though, somebody in the replies provided a serious answer to the quip: debuggers and logging. Because I use Linux, I’ve gotten quite familiar with log files – any time something doesn’t work, you have to check a log file to see where the problem lies. Without log files, you’re utterly confused; with log files, you’re a quick Internet search away from your answer. However, I never applied logging in my own programs. Firstly, they’re often so small that they’re easy to review without a log file; secondly, I just didn’t know how. It’s still bad practice, though.

Fortunately, one person linked to a really solid explanation of how debuggers work from last year’s PyCon:

It was so enlightening to watch – she described exactly how I muck around debugging my programs, using print() statements to analyze my output, adjusting it, and so on. Clearly, my bad habit was a common amateur move that happened often enough for her to be motivated to tell people about this debugger. Not only does it look like a good habit to build, the way she explains it makes it just so easy that I don’t see why I never bothered to use it in the first place.