[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 best example, but still, it was a misunderstanding. Thank you very much, Serhiy, once again! -- ___ Python tracker <https://bugs.python.org/issue42750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tkinter variables are the same Python object would be helpful." -- agreed. "Therefore, while writing 'a.get() == b.get()' isn't too bad, .." -- it isn't. But "a == b" -> False IS, provided that "a.get() == b.get()" is True. Serhiy, how about: > class Variable: > ... > def is_(self, other): # or maybe "same_as" > return self.__class__.__name__ == other.__class__.__name__ \ > and self._name == other._name > > def __eq__(self, other): > return self.__class__.__name__ == other.__class__.__name__ \ > and self.get() == other.get() Regards -- ___ Python tracker <https://bugs.python.org/issue42750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42750] tkinter.Variable equality inconsistency
Change by Ivo Shipkaliev : -- title: tkinter.Variable equality consistency -> tkinter.Variable equality inconsistency ___ Python tracker <https://bugs.python.org/issue42750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue42750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 same names in the Tcl interpreter, they are guaranteed to have the same value. >>> a = tk.IntVar(name='a') >>> b = tk.IntVar(name='a') >>> assert a == b # this is not enough; equality means "by value" # what about when they don't have the same name? >>> assert a is not b # this again does not make sense, since # both Python "a" and "b" identifiers lead to # the same "self._tk.globalgetvar(self._name)" # Tcl registered variable: name="a" >>> a.set(42); assert b.get() == a.get() == 42 # yes! # equality in names guarantees equality in value Yes ... BUT, the negation is not true: if two Tk variables have different names, that does NOT mean that they have different values. This is where we fail the equality operator: >>> c = tk.IntVar(name='c', value=42) >>> assert a._name != c._name and a.get() != c.get(), \ ... "Difference in names does not guarantee difference in value" 2. When we're interested in Tk variable comparison: .get() becomes redundant. Every time two Tk variables are of the same type AND they refer to the same value, we can safely compare them as equal, regardless of how they are named in the Tcl interpreter. -- ___ Python tracker <https://bugs.python.org/issue42750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 StrVars can hold the same strings, but are compared unequal, which doesn't seem right. Considering that we are going through the Tcl interpreter, equality should compare by value, not by identity (regardless of the variable names). Look at this, please. >>> int_0 = tk.IntVar() >>> int_0.set(51) >>> int_1 = tk.IntVar() >>> int_1.set(51) How can: >>> int_0.get() == int_1.get() True and >>> type(int_0) == type(int_1) True ..but: >>> int_0 == int_1 False This means that the equality operator is only showing the difference in their names, and the statement above loses meaning, as it can never return True. I think "int_0 is int_1" should be False as it is now. "is" should take into account their names as defined in the Tcl interpreter. But "int_0 == int_1" should be True. Same as a couple of identical Python lists with different names. Thank you! -- ___ Python tracker <https://bugs.python.org/issue42750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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")
So:
>>> str_0.get() == str_1.get()
True
But:
>>> str_0 == str_1
False
So, maybe a Variable should be compared by value, and not by identity (._name)
as currently? (please view attached) Does it make sense?
--
components: Tkinter
files: equality.diff
keywords: patch
messages: 383807
nosy: epaine, serhiy.storchaka, shippo_
priority: normal
severity: normal
status: open
title: tkinter.Variable equality consistency
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49698/equality.diff
___
Python tracker
<https://bugs.python.org/issue42750>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/file49690/default_root.diff ___ Python tracker <https://bugs.python.org/issue42672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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:
-- "master" is None
and
-- _support_default_root is True
a default root must be instantiated. A master is optional, and when it's not
given and _support_default_root switch is on, a default root should be
supplied. That's the whole point of _support_default_root after all.
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:
> "no default root window" is correct
:But why is there no default window? Support default root is on, right?
> There is no yet default root window required by the function.
: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.
I'm suggesting something like:
> class Variable:
> ...
> def __init__(self, master=None, value=None, name=None):
> ...
> master = master or _get_default_root()
> self._root = master._root()
> ...
> class Image:
> ...
> def __init__(self, imgtype, name=None, cnf={}, master=None, **kw):
> ...
> master = master or _get_default_root()
> self.tk = getattr(master, 'tk', master)
> ...
Best Wishes
Ivo Shipkaliev
--
___
Python tracker
<https://bugs.python.org/issue42630>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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:
294 > if what:
295 > raise RuntimeError(f"Too early to {what}: no default root
window")
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
--
___
Python tracker
<https://bugs.python.org/issue42630>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue42630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: 333 > master = setup_master(master) 334 > self._root = master._root() But: > from tkinter.ttk import setup_master leads to a circular import error. I'll look into this. -- ___ Python tracker <https://bugs.python.org/issue42630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 > self._root = master._root() -- resolution: -> works for me ___ Python tracker <https://bugs.python.org/issue42630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.__init__ raise a RuntimeError instead of obscure AttributeError -> Variable.__init__ to raise a RuntimeError instead of obscure AttributeError ___ Python tracker <https://bugs.python.org/issue42630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue42630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 be assigned to me, please?
Best Regards
Ivo Shipkaliev
--
components: Tkinter
messages: 382944
nosy: shippo_
priority: normal
severity: normal
status: open
title: Variable.__init__ raise a RuntimeError instead of obscure AttributeError
type: behavior
___
Python tracker
<https://bugs.python.org/issue42630>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
PEP 572 -- Assignment Expressions
Hello. Maybe it's too late for a discussion, but I just couldn't resist. I just found out about this new ":=" operator. I need to ask: What is the need for this additional ":" to the "="? Why: if (match := pattern.search(data)) is not None: # Do something with match What is wrong with: if match = pattern.search(data) is not None: # Do something with match Assignment expression or assignment statement, it's an assignment, right? It is very clear to everyone that it's an assignment! Can't it all just be a "="? Thank you very much! Kind Regards Ivo Shipkaliev -- https://mail.python.org/mailman/listinfo/python-list
