Of course programming a calculator object (e.g. oc = Calc()) might seem a bit shallow or superficial, given the behind-the-scenes functions will be somewhat black boxy, just like the calculator itself. In Python, we'd likely wire the cosine button math.cos and be done with it (nothing wrong with that solution). Was any new trig learned or discovered by this maneuver?
However, I'm thinking the calculator is valuable on several axes or dimensions. For one, it presents a very familiar, yet a complicated API. It's similar to the typewritter keyboard in this respect (e.g. QWERTY). So many buttons, plus likely a shift key or even two, to reach the color-coded alternatives (again, similar to a shift key -- sometimes these are called meta keys or context keys in CS).
The calculator API is a delegate or representative from the world of "control panels" more generally. Here the paradigm might be the cockpit of a modern jet airplane, or the space shuttle, or the bridge of an ocean-going vessel. or [ fill in the blank ]. Lots of graphical widgets. On the computer, we get large widget libraries and paint instrumentation to a canvas object.
Since we're not physically manipulating metal electronic devices here, it's more realistic to imagine reconfiguring the control panel over and over, trying out different displays.
If we ever commit to a physical version, it'll likely be after exhaustive testing in simulators.
So the calculator project is perhaps mostly a bridge. It takes us from a familiar physical device, sold in grocery stores (along with other school supplies) to something analogous on the screen (isomorphic in the API dimension i.e. the emulated version faithfully renders the interface, and then some).
Once on screen, and familiar with this behind-the-scenes language for responding to GUI events (e.g. mouse clicks, key presses), we're ready to pioneer further, with different styles of control panel ("not in Kansas any more" widget sets, skins, bells and whistles), and calls to a backend codebase that does *not* simply duplicate a scientific calculator's.
This is the breakthrough connection between math world and videogames: a real time API (control panel) used in some simulation (game) that student mathematicians needed to wire up (e.g with Python) to a backend engine (the game engine, or simulator). At this stage (of GUI programming), various design patterns get discussed, such as subscribers (to button events) and MVC (see firstname.lastname@example.org this month for more on MVC and design patterns more generally). But that's not where the story ends. We must explore the model, the engine, the guts of the back end. The spine, the brain of this program. That's not trivial. Think of Qhull.
So this is a peak at what a math/CS hybrid might look like: we have enough coding knowledge in a specific language to actually wire GUIs (control panels) and we use this skill to explore simulated realities and/or imaginary worlds wherein mathematical principles get demonstrated or accomodated. It won't just be the playing of the game that teaches the underlying math real time. The play will be positive reinforcement, enjoying something you've in large measure made yourself. It'll be in both wiring up the engine, and studying how this engine works, that we'll get more deeply into the math. E.g. some modern game engines employ quaternions instead of rotation matrices. Let's explain what that means to our eager would-be math/CS hybridizers.