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.

Jamal
35.2k13 gold badges134 silver badges238 bronze badges
asked Oct 19, 2017 at 15:15
\$\endgroup\$

2 Answers 2

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().

answered Oct 19, 2017 at 15:51
\$\endgroup\$
1
  • \$\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\$ Commented Oct 19, 2017 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.

answered Oct 19, 2017 at 17:21
\$\endgroup\$
2
  • \$\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\$ Commented Oct 19, 2017 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\$ Commented Oct 19, 2017 at 17:45

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.