-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variable.__init__ raises obscure AttributeError #86796
Comments
Hello. I think it would be nice to add: 335 > if not master: to lib/tkinter/init.py, and not rely on this unclear AttributeError. Could it be assigned to me, please? Best Regards |
Or maybe: 333 > if not master: |
Sorry, we need "global" too: 333 > if not master: |
+1 I agree the current AttributeError is not suitable. I would just copy the code from Lib/tkinter/init.py:2524 (or even better: refactor it into its own method to avoid duplication). The code there, though, would raise a similar AttributeError if the default root is disabled, so I suggest that needs a changing to possibly a TypeError (i.e. missing 'master' argument). I assume you are alright to create a PR for this? Please revert the "resolution" field as this is intended to be the reason for issue closure. |
Actually it may be worth to reuse setup_master() from tkinter.ttk. But I am not sure what is better: raise error (RuntimeError) if the global function uses _default_root which is not initialized, or create the root widget implicitly. Currently AttributeError or NameError is raised. |
The current implementation is already relying on _some_ master anyway: 335 > self._root = master._root() So, initializing a default root, if one isn't present, shouldn't break anything. And reusing setup_master() is a good idea. Maybe: 333 > master = setup_master(master) But:
leads to a circular import error. I'll look into this. |
Attached is a diff which moves the logic for I guess my question is whether we are limiting most changes to just __init__.py or whether we want to do more of a cleanup throughout the tkinter module (e.g. tkinter.dialog.Dialog can be neatened and no longer needs to inherit the Widget class). |
"Attached is a diff which ..." -- Much nicer! Are you gonna submit a PR so I can eventually use _setup_master() in my PR? |
I think I assumed you would incorporate it into your PR unless you would prefer it to be separate? |
Don't haste. I am currently working on a large PR with many tests. |
Thank you very much, fellows! Serhiy, I'm lloking at Lib/tkinter/init.py changes. I'd like to share my thoughts on this: I understand your concern: "But I am not sure what is better: raise error (RuntimeError) if the global function uses _default_root which is not initialized, or create the root widget implicitly." In the new _get_default_root() function, first we check if Support Default Root in on: 290 > if not _support_default_root: If we get passed this block, we know that Support Default Root is on, meaning that all entities that require a master, but didn't receive one passed-in, must receive a default one. That's how I perceive the whole idea behind Support Default Root. But later on we do: 293 > if not _default_root: At this point, if "what" evaluates to True, we raise a RuntimeError. But at this same time Support Default Root is on, and there is no default root. And clearly: ".. no default root window" error contradicts the "_support_default_root" idea. So further on, assuming Support Default Root is on, if we instantiate a Variable with master=None, we would get: "Too early to create variable: no default root window", which makes no sense. In my view, we should always create a default root if it's needed, provided that _support_default_root is True. Simply: Support Default Root must lead to a default root. Best Regards |
I somewhat disagree. I think Serhiy has done a very good job (in what I've reviewed so far) of balancing when a new root should or shouldn't be created (e.g. does it make sense to create a new root when calling We also have the consideration of backwards compatibility as some weird script may rely upon such errors to, for example, detect when a root has not already been created. |
Currently, a root window is created implicitly only when you create a Tkinter or Ttk widget. i.e. things which should be visible to user. When you create image, variable, or use global utility function like getbool() or mainloop() or image_types() it raises an error: AttributeError or NamedError, or sometimes RuntimeError with error message like "Too early to create image: no default root window". With PR 23781 it will always raise RuntimeError instead of AttributeError or NamedError with corresponding error message. "no default root window" is correct. There is no yet default root window required by the function. After you create it, explicitly or implicitly, you could use that function. It could be odd if image_type() will successfully return a result with a side effect of popping up a window. |
First: thank you!
I'm not saying he ain't! More so, I greatly appreciate everyone's time and effort. But I'm discussing the implementation here, not somebody's work. Apparently I haven't been precise enough in conveying my message. Let me try to clarify what I mean. Consider the following: An object gets initialized. The object's constructor accepts a "master" optional parameter (e.g. Variable.__init__). So, every time: My understanding of the module is not as deep as yours', but getboolean(), mainloop() and image_types() shouldn't be affected. "Too early to create image: no default root window": Why isn't there? When _support_default_root is on. Again, I can see that:
:But why is there no default window? Support default root is on, right?
:A default root is required when you instantiate an Image without a "master". It's not required as an argument, but it is required for the operation of Image.
Best Wishes |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: