Cheryl Sabella added the comment: Instead 'hackish', maybe I should have used 'magic'. The overloading just wasn't obvious to me, meaning I have:
self.font_bold = tracers.add(BooleanVar(parent), self.var_changed_font) self.space_num = tracers.add(IntVar(parent), ('main', 'Indent', 'num-spaces')) We defined VarTrace as being (var, callback) pairs and the second example isn't sending a function. So, even though I understand what we're doing, I wanted to ask about using different names for my own education. I was even thinking of a different interface -- add(var, callback=default, config=None) If config was specified even for the non-default callbacks, then each var could have its config defined at create time instead of in the var_changed* function. This wouldn't work for theme/keys `name` and `name2` though (I think that's the only one with two add_option calls). If the callback didn't have a changes.add_option, then it can send None for config. I hadn't thought of separating `parent`, but I like that idea. It fits in with the rest of how the widgets are created. So, if both changes were incorporated: self.font_bold = tracers.add(parent, BooleanVar, callback=self.var_changed_font, config=('main', 'EditorWindow', 'font-bold')) self.space_num = tracers.add(parent, IntVar, callback=default, config=('main', 'Indent', 'num-spaces')) Maybe that expands VarTrace too much? Or maybe instead of (var, callback) pairs, it's a dictionary? tracers = {var: (callback, config)} And then the non-default var_changed methods could use: changes.add_option(*tracers[var].config, value) Wouldn't work for var_changed_font because that has the three add_option calls. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30853> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com