As someone relatively new to the world of programming, I’m always looking for resources that will help me become more experienced. I had read the name Project Euler countless times, but had attempted to work through the problems before, and ultimately became annoyed at the process of solving the problems. I had to switch between writing code in Sublime Text, debugging the output in Terminal, and finally, comparing my solution to the accepted solution found somewhere on the Internet. Because of this, I put Project Euler on the backburner.
When learning about the world of programming, I was fascinated by the fact that you could install packages or formulae with a simple
pip install or
brew install command from the terminal and instantly be able to run it, and was determined to write my own package (if only for the novelty of being able to
pip install something that I had written).
It wasn’t until a few weeks ago that the thought of going through the Project Euler problems revisited my mind, and of course, it was during the point of time when Project Euler was down. Remembering my prior experience with Project Euler, I set out to write a tool that would streamline the process of solving problems — EulerPy. Essentially, it helps with two aspects of Project Euler: it creates a file containing a docstring with the problem as its body (for reference), and it verifies whether a problem has been solved correctly.
I started out with an idea where the script would parse the problem’s page on Project Euler using a library like Beautiful Soup in order to determine the problem body. I had a working prototype and was testing it on problems, and all seemed to be well until I got to problem #4, where the times symbol is displayed as an image rather than a character. I then did some searching and found a feature on Project Euler where a minimal version of the problem text could be accessed through a
/minimal=n page where
n is the problem number. However, I think that this functionality was linked to the Project Euler account system, and since it was only brought back as a static site, it is not accessible anymore. While I could have improved the logic of the script to automatically translate images to their text-based equivalents, I realize that this wasn’t the best solution at all, since it would require Internet access to fetch new problems.
After some more searching, I came across Kyle Keen’s Local Euler project, which contains a text-only version of problems 1 through 202, which was plenty to get started with, so I rewrote the script to read from a modified version of this text file. There’s probably a much better way to store the problems that I’m simply not aware of, but I figured a text file is fairly good considering it can easily maintained.
Making use of Armin Ronacher’s click library to parse command line arguments, I put together EulerPy. I tried to make it as easy as possible to solve Project Euler problems. With this goal in mind, I wrote the package so that it would check the output of a
.py file containing the attempted solution to the problem. Because of this, some of the problems can be solved with simple
euler to move on to the next problem.
Also convenient is the fact that the
euler command itself will automatically print the output of the Project Euler file to the terminal. Because of this, debugging is made (ever so slightly) easier by the fact that you don’t need to switch between two different commands when testing the output of the problem file and verifying if it outputs the correct solution.
Having just been introduced to Travis CI after setting it up to automatically deploy the latest version of my website, I figured it would be interesting to set it up for EulerPy as well. I ended up writting a couple of simple tests to ensure anyone updating
problems.txt had not transcribed the problems in an errant fashion.
Hopefully there aren’t too many faux pas in my coding, as EulerPy is one of my first Python projects.