[issue42750] tkinter.Variable equality inconsistency

Ivo Shipkaliev added the comment: Yes, I get it now. I've missed the idea. You can do: > age = tk.IntVar(value=38, name="mine") > age_str = tk.StringVar(name="mine") > is_alive = tk.BooleanVar(name="mine") > is_alive.get() True Maybe not the bes

[issue42750] tkinter.Variable equality inconsistency

Ivo Shipkaliev added the comment: "I personally think that being able to compare whether two tkinter variables point to the same Tk variable is very useful so needs to stay in some form." -- I concur. "However, I don't see any situation where comparing to see if two tk

[issue42750] tkinter.Variable equality inconsistency

Change by Ivo Shipkaliev : -- title: tkinter.Variable equality consistency -> tkinter.Variable equality inconsistency ___ Python tracker <https://bugs.python.org/issu

[issue42750] tkinter.Variable equality consistency

Ivo Shipkaliev added the comment: 2. (continued) .. This is including the case when both variables have the same internal name (the current implementation). -- ___ Python tracker <https://bugs.python.org/issue42

[issue42750] tkinter.Variable equality consistency

Ivo Shipkaliev added the comment: There are 2 good reasons for making Tk variables comparable by value: 1. We honor the equality operator! The equality operator (==) has to compare two objects by value. The current implementation does not fulfil this. Yes, if two Tk variables have the

[issue42750] tkinter.Variable equality consistency

Ivo Shipkaliev added the comment: If it's gonna break existing code -- fine. I just wanted to point out that if two variables are of the same type and refer to the same value, they should be considered equal, even if they are not the same variable. In the current implementation, two St

[issue42750] tkinter.Variable equality consistency

New submission from Ivo Shipkaliev : Greetings! I just noticed: >>> import tkinter as tk >>> root = tk.Tk() >>> str_0 = tk.StringVar() >>> str_0.set("same value") >>> str_1 = tk.StringVar() >>> str_1.set("same value")

[issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()

Ivo Shipkaliev added the comment: Thank you! -- ___ Python tracker <https://bugs.python.org/issue42672> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()

Change by Ivo Shipkaliev : -- components: Tkinter files: default_root.diff keywords: patch nosy: shippo_ priority: normal severity: normal status: open title: tkinter/__init__.py raises a NameError if NoDefaultRoot() type: behavior versions: Python 3.10 Added file: https

[issue42630] Variable.__init__ raises obscure AttributeError

Ivo Shipkaliev added the comment: First: thank you! > I think Serhiy has done a very good job ... 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 ha

[issue42630] Variable.__init__ raises obscure AttributeError

Ivo Shipkaliev added the comment: 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 use

[issue42630] Variable.__init__ raises obscure AttributeError

Ivo Shipkaliev added the comment: "Attached is a diff which ..." -- Much nicer! Are you gonna submit a PR so I can eventually use _setup_master() in my PR? -- ___ Python tracker <https://bugs.python.o

[issue42630] Variable.__init__ raises obscure AttributeError

Ivo Shipkaliev added the comment: 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:

[issue42630] Variable.__init__ raises obscure AttributeError

Change by Ivo Shipkaliev : -- resolution: works for me -> ___ Python tracker <https://bugs.python.org/issue42630> ___ ___ Python-bugs-list mailing list Un

[issue42630] Variable.__init__ to raise a RuntimeError instead of obscure AttributeError

Ivo Shipkaliev added the comment: Sorry, we need "global" too: 333 > if not master: 334 > global _default_root 335 > if not _default_root: 336 > _default_root = Tk() 337 > master = _default_root 338 >

[issue42630] Variable.__init__ to raise a RuntimeError instead of obscure AttributeError

Ivo Shipkaliev added the comment: Or maybe: 333 > if not master: 334 > if not _default_root: 335 > _default_root = Tk() 336 > master = _default_root 337 > self._root = master._root() -- title: Variable._

[issue42630] Variable.__init__ raise a RuntimeError instead of obscure AttributeError

Ivo Shipkaliev added the comment: https://mail.python.org/archives/list/python-id...@python.org/thread/FSQUFJJQDNSRN4HI7VFXWCNO46YLXQDS/ -- ___ Python tracker <https://bugs.python.org/issue42

[issue42630] Variable.__init__ raise a RuntimeError instead of obscure AttributeError

New submission from Ivo Shipkaliev : Hello. I think it would be nice to add: 335 > if not master: 336 > raise RuntimeError('a valid Tk instance is required.') to lib/tkinter/__init__.py, and not rely on this unclear AttributeError. Could it b