Intro: The Eternal Struggle of Old Codebases
If you’ve ever worked on an open-source project or even just inherited an old codebase, you know the pain. Code that hasn’t been updated in years, outdated libraries, cryptic comments (if any), and a general feeling of what the heck is going on here?
So, what a wild way to do a pilot test😉, by revisiting a program/game I made about ten years ago called Football (don’t judge me). What's this code, and why am I digging it up? Well, Sugar Desktop, a Linux desktop for learning primarily aimed at kids, encourages folks to create apps for children. When I wrote this app, I was super into gaming on my One Laptop Per Child (OLPC) machine, so I whipped up a Python script and got it running. But now, I'm curious about how that code would look in 2025, especially with all the AI buzz.
Initially built in Python 2, Sugar Desktop required a major migration to Python 3, and modernizing legacy code is like trying to fix an old car. Some parts are easy to replace, but other things are just... well, obsolete, and my Python skills are rusty. What if AI could help?
Enter GitHub Copilot, the AI-powered code assistant that promises to help developers write, refactor, and modernize code faster. But can it actually help when it comes to upgrading real legacy projects? To find out, I put Copilot to the test by migrating the application/ activity from Python 2 to Python 3.
The results? Interesting, to say the least.
What is GitHub Copilot, and Why Does It Matter?
GitHub Copilot is like having an AI-powered buddy sitting next to you, suggesting code as you type. It’s trained on tons of open-source code and tries to predict what you need based on the context of your project.
Cool Things Copilot Can Do:
Suggests whole functions, not just single lines of code.
Works in VS Code, JetBrains, and Neovim.
Understands comments and generates code based on them.
Learns from your coding style over time.
Sounds impressive, right? But how well does it work when dealing with ancient code that desperately needs an update?
Use Case: Migrating a Sugar Desktop Activity to Python 3
The Football activity is a Flash-based game using Gnash, an outdated SWF player. The original code was written in Python 2 and used the deprecated Sugar Toolkit (GTK2).
Here’s a snippet from the original implementation:
import os
import gtk
try:
import gnash
except ImportError:
import subprocess
from sugar.activity import activity
SWFNAME = 'Football.swf'
class FootballActivity(activity.Activity):
def __init__(self, handle):
activity.Activity.__init__(self, handle)
toolbox = activity.ActivityToolbox(self)
self.set_toolbox(toolbox)
toolbox.show()
try:
view = gnash.View()
view.props.uri = os.path.join(activity.get_bundle_path(), SWFNAME)
self.set_canvas(view)
view.show()
except NameError:
socket = gtk.Socket()
self.set_canvas(socket)
self.show_all()
args = [
'gnash',
'-x', str(socket.get_id()),
os.path.join(activity.get_bundle_path(), SWFNAME)
]
self._process = subprocess.Popen(args)
This code had several issues:
It uses Python 2, which is dead. (RIP, Python 2. You had a good run.)
Used gtk (GTK2) instead of gi.repository.Gtk (GTK3)
Relied on gnash, an SWF player that no one supports anymore.
Used Python 2 syntax (old-style exception handling, print statements, etc.)
Used sugar.activity instead of sugar3.activity
Clearly, this needed some serious upgrading.
How Copilot Assisted with the Migration
I enabled Copilot in VS Code and started refactoring the code to Python 3 and Sugar3. Here’s what happened.
Syntax Upgrades Were a Breeze
- Simply typing a comment like
# Convert to Python 3 prompted Copilot to refactor many parts of the code, replacing import gtk with from gi.repository import Gtk and fixing exception handling.
Structural Recommendations
- When rewriting the class, Copilot automatically suggested modern Sugar3 methods, which saved me a lot of lookup time.
Handling Deprecated Dependencies? Not Quite
- While Copilot recognized
gtk needed replacement, it did not know about the deprecation of Gnash and suggested irrelevant alternatives. This required manual intervention.
The Final Code: A Cleaner, Modernized Version
After some back-and-forth with Copilot (and a bit of manual intervention), here’s the updated version:
import os
from gi.repository import Gtk
import subprocess
from sugar3.activity import activity
SWFNAME = 'Football.swf'
class FootballActivity(activity.Activity):
def __init__(self, handle):
super().__init__(handle)
toolbox = activity.ActivityToolbox(self)
self.set_toolbox(toolbox)
toolbox.show()
view = Gtk.DrawingArea()
self.set_canvas(view)
view.show()
socket = Gtk.Socket()
self.set_canvas(socket)
self.show_all()
args = ['gnash', '-x', str(socket.get_id()), os.path.join(activity.get_bundle_path(), SWFNAME)]
self._process = subprocess.Popen(args)
def close(self):
if hasattr(self, '_process') and self._process:
self._process.terminate()
super().close()
How Copilot Helped
1. Converting GTK 2 to GTK 3 (gi.repository.Gtk)
By adding a comment in VS Code—
# Convert gtk.Socket() to GTK 3
Copilot suggested:
from gi.repository import Gtk
socket = Gtk.Socket()
self.set_canvas(socket)
self.show_all()
✅ Success! Copilot correctly replaced gtk with gi.repository.Gtk.
2. Fixing Activity Initialization
The original activity used sugar.activity, which needed updating to sugar3.activity. Copilot suggested:
from sugar3.activity import activity
✅ Correct fix! This ensured Sugar3 compatibility.
Where Copilot Struggled
1. Understanding Sugar3-Specific APIs
While Copilot was great at general Python fixes, it struggled with Sugar-specific APIs. For example, it failed to:
These had to be manually fixed using Sugar’s developer documentation.
2. Over-Reliance on Generic Suggestions
Copilot occasionally suggested unrelated solutions—like using PyQt instead of GTK. This is a reminder that AI-generated code must be reviewed.
Final Thoughts: Is Copilot Useful for Open Source Maintenance?
✅ Pros:
Great for refactoring repetitive patterns (e.g., updating imports, subprocess handling).
Speeds up migration work by suggesting best practices.
Improves productivity for developers familiar with AI-assisted workflows.
❌ Cons:
Lacks a deep understanding of project-specific APIs (e.g., Sugar3).
Still requires manual review and debugging.
Verdict:
GitHub Copilot is a useful AI assistant, but not a replacement for human developers. It can automate simple tasks, but specialized knowledge is still necessary, especially in niche open-source projects.
Would I use Copilot again for a migration like this? Absolutely. But I’d also keep Stack Overflow, project docs, and a healthy dose of skepticism on hand.
What’s Next?
As AI improves, tools like Copilot will become even more useful in maintaining open-source projects. But for now, AI-assisted coding works best as a co-pilot (pun intended) rather than a full autopilot.
If you're working on an open-source migration, give Copilot a try, but always review its code before merging!
What do you think, would you trust AI to upgrade your old code? Let’s chat in the comments!
