2
\$\begingroup\$

I am doing a small GUI program for a practice exercise and in order to save myself some typing I took it upon myself to subclass some Tkinter widgets so I can pass the grid placement in the instantiation. One of my subclasses looks like this:

import tkinter as tk
class EntryBox(tk.Entry):
    def __init__(self, master=None, width=1, relief=None, row=None, column=None, sticky=None, padx=None, pady=None, **kwargs):
        super().__init__(master=master, width=width, relief=relief, **kwargs)
        self.grid(row=row, column=column, sticky=sticky, padx=padx, pady=pady)

And one of my instances of this widget looks like this:

window = tk.Tk()

title_entry = EntryBox(window, 10, 'sunken', 0, 1)

window.mainloop()

My initial thinking for the subclass is that if I am creating these entry widgets, they will clearly be visible on the screen (similar for some Labels, text areas, buttons, etc...). So this would save many lines of code and typing.

Is it appropriate to subclass these widgets to save typing, or does this typically cause more confusion when another programmer reads it? Also, will this be considered more error-prone? (Perhaps it would still be best to pass named parameter in my instantiation?)

I'd like to get some comments on when it's good practice / appropriate to subclass and when it causes more confusion.

I wanted to add that I decided to pass default values in the init subclass method so that if someone wanted to call the grid methods in the traditional way they still could in the code.

\$\endgroup\$
1
\$\begingroup\$

It is perfectly normal to attempt to subclass a Tkinter widget to create a custom one. Your choice is valid and justified.

However, as Tkinter does not have a EntryBox() class, it would be better to rename this, in order not to confuse the reader of your code, to rename it to something like: CustomEntry() or, why not, CustomEntryWidget().

\$\endgroup\$
  • \$\begingroup\$ That makes sense, thanks. My main hesitation would be to cause confusion if someone were to read my code but that would be more clear. 👍 \$\endgroup\$ – Hanzy Oct 19 '17 at 15:52
1
\$\begingroup\$

Subclassing a widget is perfectly fine, though I don’t think it’s wise to include the call to ‘grid‘. Doing so tightly couples it to the caller. A widget shouldn’t be responsible for knowing how the caller is going to use it.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the feedback, I appreciate it. I'm curious if you could expand on why it might not be wise to call the grid method at instantiation? For example, my thinking was that the widgets I subclassed would all be displayed on the screen, so my thought was that I could save myself lines of code by passing arguments to the instance. I also considered a parameter in init grid=False like this: def __init__(self, master=None, grid=False), then using something like if grid=True: self.grid(args here). \$\endgroup\$ – Hanzy Oct 19 '17 at 17:42
  • \$\begingroup\$ I'm curious what are the circumstances where it's beneficial to have the grid separate from the instantiation. (Clearly there must be cases because that's the default method provided, so I'm just wondering when / if it would be best left to call the grid method separately). \$\endgroup\$ – Hanzy Oct 19 '17 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.