I still remember the first time I needed a tool that didn’t exist: a tiny editor that could run a single file, show output, and format code exactly how my team preferred. Every mainstream IDE felt heavy for that task, and editors felt too bare. That gap is where building your own Python IDE becomes practical, not just a fun weekend project. You get a tool that fits your workflow, helps you learn GUI design and code execution boundaries, and gives you a safe place to experiment with editor features you might want in a larger app.
In this post, I walk you through building a focused, modern Python IDE using Python itself. I’ll start with the core window, then layer in execution, output capture, and editor ergonomics. I’ll also show how to add guardrails, where things go wrong in real use, and how to think about performance in the small. You’ll leave with a runnable base that you can expand into something you genuinely want to use for real work.
Why build your own IDE
Most IDEs are designed for broad audiences. That’s great, but it also means you inherit a lot of choices you didn’t make: shortcuts, panels, project models, and workflows. When you build your own, you’re forced to think about what an IDE really is: an editor, a runner, and a feedback surface. That shift makes you a better engineer because you see the moving parts clearly.
I recommend this project when you want to:
- Learn GUI development in Python without getting lost in a huge framework
- Control the run loop and output formatting
- Create an environment for teaching, demos, or minimal automation
- Build a custom learning tool for your team or classroom
If you want features like full refactoring, rich linting, or multi-language support, you should stick with mainstream tools. But for focused Python work, a personal IDE can be a perfect fit.
The mental model: editor, runner, console
I design these apps using a three-box mental model:
1) Editor: where you write code
2) Runner: where code is executed
3) Console: where output and errors appear
This simple model maps cleanly to a GUI layout: top pane for the editor, bottom pane for output, and a “Run” button that triggers execution. When you keep the architecture this simple, you can ship a working build fast and add features without breaking the core loop.
In the rest of this post, I’ll build that loop first, then add practical improvements: line numbers, keyboard shortcuts, error reporting, and a minimal project system.
Project setup with PyQt
I use PyQt because it provides a full desktop GUI toolkit with solid widgets and layout options. It’s mature, stable, and works well for a single-file starter project. The core dependency is PyQt5 or PyQt6. I’ll use PyQt5 for compatibility with a lot of existing examples, but the structure is similar in PyQt6.
Install:
- pip install PyQt5
I also use standard library modules to capture output safely. There’s no extra runtime dependency beyond PyQt and Python itself.
A minimal, runnable IDE
Start with a single window that holds a text editor, an output panel, and a run button. Here’s a complete example you can run as a script. I’ve added comments for the non-obvious parts.
import sys
from io import StringIO
import contextlib
from PyQt5.QtWidgets import (
QApplication,
QMainWindow,
QTextEdit,
QPushButton,
QVBoxLayout,
QWidget,
QMessageBox
)
class PythonIDE(QMainWindow):
def init(self):
super().init()
self.init_ui()
def init_ui(self):
self.setWindowTitle("Python IDE")
self.setGeometry(100, 100, 900, 650)
self.editor = QTextEdit()
self.output = QTextEdit()
self.output.setReadOnly(True)
self.run_button = QPushButton("Run")
self.runbutton.clicked.connect(self.runcode)
layout = QVBoxLayout()
layout.addWidget(self.editor)
layout.addWidget(self.output)
layout.addWidget(self.run_button)
container = QWidget()
container.setLayout(layout)
self.setCentralWidget(container)
def run_code(self):
code = self.editor.toPlainText()
output_stream = StringIO()
# Capture stdout so print() shows in the output panel
with contextlib.redirectstdout(outputstream):
try:
exec(code, {})
except Exception as exc:
print(f"Error: {exc}")
self.output.setPlainText(output_stream.getvalue())
if name == "main":
app = QApplication(sys.argv)
ide = PythonIDE()
ide.show()
sys.exit(app.exec_())
This gives you a working app in under 100 lines. It reads code from the editor, executes it, and prints output to a console-like panel. That’s the simplest usable form of a personal IDE.
Why exec works, and where it can hurt you
Using exec is a fast way to run code inside your process, but it brings two risks:
- It runs with full permissions of your process
- It can lock the UI if code runs forever
For a learning tool or internal use, exec is acceptable. For any distribution or shared use, you should treat it as unsafe and isolate execution in a separate process. I’ll show how to do that later.
Improving the editing experience
A basic QTextEdit is usable, but it misses features you expect in an IDE. Here are quick wins you can add without rewriting your editor widget:
1) Monospace font and tab width
Give your editor a fixed-width font and a reasonable tab size. This improves readability and alignment.
from PyQt5.QtGui import QFont
font = QFont("Menlo", 12)
self.editor.setFont(font)
# Set tab width to 4 spaces in pixels
space_width = self.editor.fontMetrics().horizontalAdvance(" ")
self.editor.setTabStopDistance(space_width * 4)
2) Basic syntax color
A full syntax highlighter is a longer topic, but Qt makes it manageable via QSyntaxHighlighter. Here’s a lightweight version that highlights keywords and comments. It’s not a full parser, but it’s good enough for a personal IDE.
import re
from PyQt5.QtGui import QSyntaxHighlighter, QTextCharFormat, QColor
class SimplePythonHighlighter(QSyntaxHighlighter):
def init(self, document):
super().init(document)
self.rules = []
keyword_format = QTextCharFormat()
keyword_format.setForeground(QColor("#005cc5"))
keywords = [
"def", "class", "import", "from", "return", "if", "elif",
"else", "for", "while", "try", "except", "with", "as",
"True", "False", "None"
]
for word in keywords:
pattern = re.compile(r"\b" + word + r"\b")
self.rules.append((pattern, keyword_format))
comment_format = QTextCharFormat()
comment_format.setForeground(QColor("#6a737d"))
self.rules.append((re.compile(r"#.*"), comment_format))
def highlightBlock(self, text):
for pattern, fmt in self.rules:
for match in pattern.finditer(text):
start, end = match.span()
self.setFormat(start, end – start, fmt)
Use it in init_ui:
self.highlighter = SimplePythonHighlighter(self.editor.document())
3) Line numbers (optional but useful)
Line numbers are more involved because QTextEdit doesn’t provide them out of the box. A clean approach is to subclass QPlainTextEdit, which is lighter and built for code. For a first build, I skip line numbers. If you want them, treat that as a second iteration once the core run loop is stable.
A safer execution model
If you let code run inside the UI process, a heavy loop can freeze the window. I see this mistake most often with long-running scripts or infinite loops. The fix is to run code in a separate process and stream output back.
Here’s a minimal pattern using Python’s multiprocessing. The child process runs code and sends output lines back through a queue. The UI polls the queue on a timer.
import multiprocessing as mp
import time
def runusercode(code, queue):
output_stream = StringIO()
with contextlib.redirectstdout(outputstream):
try:
exec(code, {})
except Exception as exc:
print(f"Error: {exc}")
queue.put(output_stream.getvalue())
class PythonIDE(QMainWindow):
# … existing init_ui
def run_code(self):
code = self.editor.toPlainText()
self.output.clear()
self.queue = mp.Queue()
self.process = mp.Process(target=runusercode, args=(code, self.queue))
self.process.start()
# Poll for output every 100ms
self.timer = self.startTimer(100)
def timerEvent(self, event):
if not self.process.is_alive():
self.killTimer(self.timer)
if not self.queue.empty():
self.output.setPlainText(self.queue.get())
This isn’t perfect, but it prevents the UI from freezing and gives you a path to add cancellation later.
Building a better run experience
When I make an IDE, I want the run loop to feel predictable. Here are the improvements that matter most:
1) Clear separation of stdout and errors
Developers read errors differently from regular output. You can send errors to the output panel with a prefix, or show them in a second panel. A simple approach is to capture stderr separately.
import sys
from io import StringIO
def runusercode(code, queue):
out = StringIO()
err = StringIO()
with contextlib.redirectstdout(out), contextlib.redirectstderr(err):
try:
exec(code, {})
except Exception as exc:
print(f"Error: {exc}", file=sys.stderr)
queue.put((out.getvalue(), err.getvalue()))
Then display it with simple formatting in the UI.
2) Keyboard shortcuts
A run button is fine, but I prefer a shortcut like Ctrl+R or Cmd+R. In PyQt you can add a QAction to the window and set the shortcut.
from PyQt5.QtWidgets import QAction
run_action = QAction("Run", self)
run_action.setShortcut("Ctrl+R")
runaction.triggered.connect(self.runcode)
self.addAction(run_action)
3) Run with a clean globals dict
Using exec with a fresh dict prevents the last run’s variables from leaking into the next run. That keeps behavior consistent and avoids confusing state.
A small project model
At some point, you’ll want to open and save files. I keep it minimal: one file at a time, with Save and Save As. You can later add a project tree if needed.
from PyQt5.QtWidgets import QFileDialog
def save_file(self):
if not hasattr(self, "current_path"):
self.savefileas()
return
with open(self.current_path, "w", encoding="utf-8") as f:
f.write(self.editor.toPlainText())
def savefileas(self):
path, _ = QFileDialog.getSaveFileName(self, "Save File", "", "Python Files (*.py)")
if path:
self.current_path = path
self.save_file()
def open_file(self):
path, _ = QFileDialog.getOpenFileName(self, "Open File", "", "Python Files (*.py)")
if path:
self.current_path = path
with open(path, "r", encoding="utf-8") as f:
self.editor.setPlainText(f.read())
Add a small menu bar, and you have a practical file workflow.
Traditional vs modern workflow for a personal IDE
I often compare how I built tools a few years ago to how I build them now. In 2026, I include AI assistance in testing and generation, but I still keep human judgment as the final gate. Here’s a quick comparison.
Traditional
—
manual file setup
trial and error
print exceptions
manual clicks
long cycles
The modern flow isn’t about letting a tool write everything. It’s about reducing the boring steps so you can focus on UX and reliability.
Common mistakes and how to avoid them
Here are the most common pitfalls I see when people build small IDEs:
1) Blocking the UI: A long-running script locks your app. Fix it with multiprocessing or a worker thread.
2) Running untrusted code: exec is unsafe. Only run your own code, or isolate execution in a sandbox process.
3) Missing error context: If you swallow exceptions, debugging becomes painful. Show errors clearly in the output pane.
4) File encoding issues: Always open files with UTF-8 and fail gracefully if decoding fails.
5) No autosave or warnings: You should warn before closing unsaved work. A simple dirty flag can solve this.
When to use this IDE and when not to
You should use a personal IDE when:
- You want a focused environment for teaching, demos, or scripts
- You need a lightweight runner for a specific workflow
- You want to explore GUI and editor mechanics
You should avoid it when:
- You need advanced refactoring or deep linting
- You work with large multi-language codebases
- You plan to distribute it to unknown users without strong isolation
In my experience, the personal IDE shines as a learning and productivity tool for small, clear tasks.
Performance considerations in practice
A small IDE doesn’t need heavy tuning, but there are a few places where performance matters:
- Syntax highlighting: Per-line regex is usually fine for small files. For large files, you’ll see UI lag. That lag is typically 10–25ms per keystroke when files pass a few thousand lines.
- Execution time: Running code inside the UI thread is fine for short scripts, but anything that runs longer than 200–500ms should move to a background process.
- Output size: Rendering huge output dumps can slow the UI. I cap output to a fixed number of lines or characters, then show a warning.
These aren’t hard limits, but they are practical guardrails that keep the app feeling responsive.
Real-world scenarios and edge cases
When you start using your IDE for real tasks, you’ll hit a few tricky cases. Here’s how I handle them:
Infinite loops
If a user writes while True: pass, your runner hangs forever. A timeout or a kill switch solves this. When I run code in a process, I add a “Stop” button that calls process.terminate().
Input handling
If code calls input(), it will block. You can intercept input by overriding sys.stdin with a custom object, or you can open a dialog when input is requested. For a first version, I simply warn users that input isn’t supported.
File paths
Scripts often assume a working directory. I set the working directory to the file’s folder when running a script so relative paths behave like a normal terminal run.
Encoding errors
If a file contains non-UTF-8 content, read errors can occur. I catch UnicodeDecodeError and prompt the user to reopen the file with a different encoding.
Extending the IDE: a realistic roadmap
Once the core is stable, here’s the order I recommend for adding features:
1) Save/Open menu and dirty state
2) Keyboard shortcuts for run and save
3) External process execution with a stop button
4) Basic syntax highlighting
5) Project tree (optional)
6) Settings panel for font size and theme
Notice that I delay the fancy parts. The biggest usability gains come from file handling, a safe run loop, and basic editor ergonomics.
A focused example with file support and safer runs
Here’s a fuller example that includes open/save, a run shortcut, and process isolation. It’s still a single file and easy to extend.
import sys
import os
import multiprocessing as mp
from io import StringIO
import contextlib
from PyQt5.QtWidgets import (
QApplication, QMainWindow, QTextEdit, QPushButton,
QVBoxLayout, QWidget, QFileDialog, QAction, QMessageBox
)
from PyQt5.QtGui import QFont
def runusercode(code, queue, working_dir):
if working_dir:
os.chdir(working_dir)
out = StringIO()
err = StringIO()
with contextlib.redirectstdout(out), contextlib.redirectstderr(err):
try:
exec(code, {})
except Exception as exc:
print(f"Error: {exc}", file=sys.stderr)
queue.put((out.getvalue(), err.getvalue()))
class PythonIDE(QMainWindow):
def init(self):
super().init()
self.current_path = None
self.init_ui()
def init_ui(self):
self.setWindowTitle("Python IDE")
self.setGeometry(100, 100, 900, 650)
self.editor = QTextEdit()
self.output = QTextEdit()
self.output.setReadOnly(True)
self.editor.setFont(QFont("Menlo", 12))
self.run_button = QPushButton("Run")
self.runbutton.clicked.connect(self.runcode)
layout = QVBoxLayout()
layout.addWidget(self.editor)
layout.addWidget(self.output)
layout.addWidget(self.run_button)
container = QWidget()
container.setLayout(layout)
self.setCentralWidget(container)
self.create_menu()
self.create_shortcuts()
def create_menu(self):
menu = self.menuBar().addMenu("File")
open_action = QAction("Open", self)
save_action = QAction("Save", self)
saveasaction = QAction("Save As", self)
openaction.triggered.connect(self.openfile)
saveaction.triggered.connect(self.savefile)
saveasaction.triggered.connect(self.savefileas)
menu.addAction(open_action)
menu.addAction(save_action)
menu.addAction(saveasaction)
def create_shortcuts(self):
run_action = QAction("Run", self)
run_action.setShortcut("Ctrl+R")
runaction.triggered.connect(self.runcode)
self.addAction(run_action)
def open_file(self):
path, _ = QFileDialog.getOpenFileName(self, "Open File", "", "Python Files (*.py)")
if path:
self.current_path = path
with open(path, "r", encoding="utf-8") as f:
self.editor.setPlainText(f.read())
def save_file(self):
if not self.current_path:
self.savefileas()
return
with open(self.current_path, "w", encoding="utf-8") as f:
f.write(self.editor.toPlainText())
def savefileas(self):
path, _ = QFileDialog.getSaveFileName(self, "Save File", "", "Python Files (*.py)")
if path:
self.current_path = path
self.save_file()
def run_code(self):
code = self.editor.toPlainText()
self.output.clear()
queue = mp.Queue()
workingdir = os.path.dirname(self.currentpath) if self.current_path else None
process = mp.Process(target=runusercode, args=(code, queue, working_dir))
process.start()
process.join() # For a quick example; use a timer for responsive UI
out, err = queue.get()
combined = out
if err:
combined += "\n" + err
self.output.setPlainText(combined)
if name == "main":
app = QApplication(sys.argv)
ide = PythonIDE()
ide.show()
sys.exit(app.exec_())
This example blocks while the child process runs, so it’s not yet ideal for long tasks. I left a comment to switch to a timer loop for responsiveness. That’s a good next step once you’ve validated the core behavior.
Final thoughts and next steps
Building a personal IDE is one of the best ways to understand how editing, execution, and feedback truly fit together. You gain control over the workflow and learn a practical slice of GUI design, process isolation, and user experience. I recommend starting small, shipping a core that you can use daily, and then layering features based on real pain points.
Here’s how I would continue after this first build:
- Add a stop button and a timer-based polling loop so long runs don’t lock the UI
- Track a dirty flag and warn before closing unsaved work
- Add a simple settings dialog for font size and theme
- Improve error display with tracebacks and clickable line references
- Add a small test harness for the runner so you can validate output and errors quickly
If you follow that path, you’ll end up with a tool that fits your workflow better than any off‑the‑shelf IDE. And more importantly, you’ll understand exactly how it works because you built every part of it.
