[issue3405] Add support for the new data option supported by event generate (Tk 8.5)
O.C. added the comment: Hello, I read the proposed patch "event_generate__data2.diff" and the Tcl/Tk manual http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24 * Could you please also add a field "e.user_data" ? This would simply be a copy of 'd' : --- e.detail = d e.user_data = d --- My reasoning is that the Tcl/Tk manual mentions the two names "detail" and "user_data". However, "user_data" may often be preferred because it has a clear meaning, whereas "detail" is quite vague. * I did not understand why you try to get a widget reference from the "%d" field. Is it supposed to contain a widget name at some point ? According to the manual (and if I understood it well), it should never. Best regards, O.C. -- nosy: +dghjfrdj ___ Python tracker <http://bugs.python.org/issue3405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11194] "lock.__exit__ == lock.release" should be False
New submission from O.C. : Hello, if 'lock' is a threading.Lock, the functions lock.__exit__() and lock.release() are different. The former takes 3 arguments, while the latter takes no argument. However, "lock.__exit__ == lock.release" returns True. Shouldn't it return False ? Best regards, O.C. Details: In [20]: lock=threading.Lock() In [21]: lock.acquire() In [22]: lock.__exit__(None,None,None) In [23]: lock.locked() Out[23]: False In [24]: lock.acquire() In [25]: lock.release(None,None,None) TypeError: release() takes no arguments (3 given) In [26]: lock.__exit__==lock.release Out[26]: True -- components: Library (Lib) messages: 128409 nosy: dghjfrdj priority: normal severity: normal status: open title: "lock.__exit__ == lock.release" should be False type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue11194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11194] "lock.__exit__ == lock.release" should be False
O.C. added the comment: > Do you have a use case that this impacts? No, I can live with it. It was rather a point about clarity and consistency. For example, the difference between Lock and RLock: lock.__exit__==lock.release-> True rlock.__exit__==rlock.release -> False We came on that topic when using 'with' statements with exceptions and 'returns'. I wanted to check and understand the details, and I was confused by the fact that: - three arguments will be given to lock.__exit__() - lock.__exit__ is "the same" as lock.release - lock.release takes no argument These propositions are all true, but seem contradictory. The meaning of "the same" is not obvious in this case. -- ___ Python tracker <http://bugs.python.org/issue11194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3405] Add support for the new data option supported by event generate (Tk 8.5)
O.C. added the comment: I don't agree with this comment. 1) The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",... 2) When an event is received, the 'detail' and 'user_data' fields are de facto mixed up. Indeed, the "%d" field contains "the detail or user_data field from the event". This information comes form the documentation I cited, http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24 : * The "%d" field contains "the detail or user_data field from the event". * They are both strings: * "the %d is replaced by a string identifying the detail" * "For virtual events, the string will be whatever value is stored in the user_data field when the event was created (typically with event generate), or the empty string if the field is NULL" >From the document cited in msg165234 >(http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16), my understanding is: * For virtual events, the "data" string parameter given to "event generate" will be stored in the "user_data field" for the event. This string will then be available from the event through the "%d" substitution. * For events "Enter", "Leave", "FocusIn" and "FocusOut", the "detail" field will store a string among "NotifyAncestor", etc. This string will then be available from the event through the "%d" substitution. So, from the point of view of the guy who receives the event, the "%d" field can EITHER be a "detail" string like "NotifyAncestor" if event was "Enter"/"Leave"/"FocusIn"/"FocusOut" OR a "user_data" string in the case of a virtual event. It seems sensible that the Python interface provides both names. As a consequence, I think the patch should read: +# value passed to the data option is not a widget, take it +# as the detail field +e.data = None +e.detail = d +e.user_data = d I hope I understood the doc correctly. -- ___ Python tracker <http://bugs.python.org/issue3405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
