Python is really powerful and relatively easy to learn – but that doesn’t mean that everyone can just run your Python scripts.
There’s a bit of a learning gap, even if it’s just how to carefully enter command-line arguments. And when you enter those wrong, the errors can be pretty unforgiving. Or worse, have some nasty side effects.
This is where a graphical user interface (GUI) comes in. A GUI can help anyone use your Python scripts safely and confidently:
- let users run Python scripts independently
- provide a job-specific interface to enforce limited input
- limit who can do what with a Python script in that given situation
- give “immediate visual feedback” (aka lets you know when you’ve forgotten a required form, for example)
- are meant to be intuitive and easy to use for anyone
- make inaccessible technology accessible (especially for Linux)
Of course, it’d be ideal to have a custom GUI for your scripts built by a specialist like a UX engineer using a desktop framework like Tkinter or a web application like Django. But unfortunately, that would be extremely expensive and slow to roll out.
In this article, I’ll walk you through why you need GUIs, what mistakes to avoid, and how to simply create a GUI around your Python Scripts.
Two (Not Great) Options for Building Python GUIs
Use Tkinter to Create a GUI
Tkinter is the leading choice for Python users creating GUI’s. It’s a standard cross-platform UI library that makes creating a GUI much “easier.”
If you’re new to creating GUI’s in Python the basic steps are to:
- Import the Tkinter module:
top = Tkinter.Tk()
- Create the GUI main window that will “house” your GUI and widgets.
- Add whatever widgets your GUI needs including buttons, labels, lists, etc.
It’s important to note, all of this is done via code, Tkinter is not a drag-and-drop GUI creator. There are many great guides out there to help point you in the right direction if this is a route you’re looking to go down. However, I’d think twice before heading down this path.
Without extensive pre-existing UI, Python, and Tkinter skills, it’s a struggle to cobble together a half-decent GUI with Tkinter.
UI specialists have an in-depth understanding of what it takes to make a good GUI, without that insight you’ll find yourself creating a GUI that you’d like, not one your end-user needs. On top of that, without extensive knowledge of all the Python libraries you need, you’ll find most of your time is spent researching modules, libraries, and dependencies. All of those libraries mean an incredible amount of new code. We’re talking about bloating your current script up to 10 times its current size.
Because of how involved they are, most teams find they lean towards creating something simpler like a text-based menu. But those are far from perfect too.
It’s much easier to text-based menus for your Python scripts. But one must ask a philosophical question: Is a text-based menu even “graphical”?
I’ve wrestled with the answer and come to the wobbly conclusion that it isn’t really a GUI but it’s close enough to be considered one in this context.
There are many guides outlining creating a text-based menu for Python. Alternatively, you could use the built-in module curses that supply a terminal-independent screen-painting and keyboard-handling facility for text-based terminals. But the general steps to building a bare-bones text-based menu is to:
- Modify your script to use functions as needed
- Create a program loop with something like while
- Prompt for a choice with something like
choice = input("Select option: ")
- Use if/else statements to determine what function to call based on the input, or exit
While this is much easier than using Tkinter, the effort put in is reflected clearly in the final deliverable. Text-based menus can’t accommodate “modern luxuries” or standards like checkboxes, drop-down menus, or even auto-complete. Text-based menus shift the burden onto the user and require them to be much more technically capable. Without the guidance of something like a drop-down menu, it’s very possible that some of your users won’t be able to use a text-based menu confidently.
So, while text-based menus are slightly easier to create, they arguably don’t fix the problems that a GUI is supposed to solve.
Running Scripts with Auto-generated UIs
Auto-generated UIs are the solution for teams that need to quickly set up restrictions without the cost of creating an interface.
Otter can automatically generate a GUI around your script and does it in two ways
- Comment Headers
- Otter’s job template feature
Otter Auto-Generated GUI
If you’re already in the practice of creating comment headers for your Python scripts, creating an auto-generated GUI is easy. Otter can parse and create a GUI around your comment headers. You’ll want to follow a few Comment Header rules and it can get quite complicated, but you don’t need to use all the comment header options available.
I uploaded a Python script and set the following parameters and options:
- interface_name: name of the interface to update
- ip_address: new IP address
- ip_netmask: new IP netmask
- mock (switch): indicates whether the RESTCONF calls will be executed
In Otter, you can also create further restrictions with a Job Template. Otter allows you to create a template that restricts inputs when running a script AND will prompt a reminder when a user has forgotten to fill out the required fields. Job templates let you define variable prompts, time restraints, and even what server a specified script can run on.
Why Auto-Generated GUIs Are the Better Choice
It really boils down to three very simple reasons:
- GUIs are automatic – no extra time spent making a GUI by hand
- Python scripts previously impossible for someone in, say, Accounting to run are now runnable because they’re in a simple GUI made-to-order by Otter
- Any GUI you build will bloat your script and make it much more complex.
Creating a GUI yourself with Tkinter or a text-based menu adds another thing on your plate, another asset you and your team have to maintain. Let’s say for example you create a Python script to open two ports and close two other ports. Then a few weeks later, your team decides a third port needs to be opened. Any GUIs your team created for that script now have to be edited.
To top it all off, we’ve only mentioned the GUI you created that a human user will interact with. As the saying goes, anything worth doing is worth automating (I may have misremembered it.) But the point stands that automation is a core part of any modern team’s processes. Supporting two usage models (interactive and automated) means more code and more bloat that you don’t need.
At the end of the day, you do less work and have a more useful UI by automating the GUI creation.
Automation Is the Key
GUIs made by Otter are automatic and are easily customized. Python scripts previously impossible for someone in, say, Accounting to run are now runnable because they’re in a simple GUI made-to-order.
Otter doesn’t just let your non-expert Python users run scripts; it also allows those in charge to sleep more soundly at night by targeting only specific servers for a particular job or job template.
Using and optimizing Python at your organization is a complex puzzle to solve and GUI’s are just the beginning. To learn more, sign up to receive your free “Python in the Enterprise” guide!