You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PEP 3121, 384 Refactoring applied to tkinter module #59926
Changes proposed in PEP-3121 and PEP-384 have now been applied to the tkinter module!
When running the test form inside Python.exe (tkinter._test()), the litte "test-window" is rendered correctly. However there are still some error messages popping up inside the python shell
(I am running this on OS X 10.8):
I would to have all module state inside _tkinterstate structure.
static variables like tcl_lock, tcl_state, quitMainLoop, errorInCmd etc should be moved into _tkinterstate also.
RobinSchreiber commented on Oct 6, 2012
RobinSchreibermannequin
MannequinAuthor
More actions
Before I submitted this patch, I used to have these variables inside the modulestate, which caused severe problems. I do not know the exact reason, but my guess is that these variables have to be globally available for every thread (tcl variables are used for thread synchronization arent they?). As the modulestate may change depending on the thread, one can no longer guarantee that every thread within the process is operating on the same variable. This might not be nessecary, however as I mentioned, the naive approach of putting the variables inside the modulestate did not work out for me.
Submit patch which store own state into module state.
Still not finished yet: need to add checks for "ready state" in every access to fields of module state structure.
Upload version which check if _tkinter module was destroyed (for example, if it was call from daemon thread runing Tk app when main thread is exiting with interpreter finalization).
I have questions about the following part of commit bf9d118779f5:
+ PyTclObject_Type_slots[3].pfunc = PyObject_GenericGetAttr;
First, the "3" refers to the position of Py_tp_getattro in the array, which is a fragile thing IMO.
Then, this hack was not necessary before; why is it needed now?
IIRC on Windows a static initializer cannot contain dll-imported variables, but function pointers are OK.
Or do you have evidence of the contrary?
Amaury, I completely agree with your objection.
I've found this code in xxlimited.c and adapted to _tkinter source.
If that weird code can be removed I will do it.
I have no idea how we can catch/reproduce the problem, maybe Martin von Loewis can help as author of xxlimited.c code?
As I know almost nobody make PEP-384 compliant modules for now and maybe there are couple of dark corners at least in the docs.
See also bpo-15650 for another question related to adaptation to PEP-3121.
The first two patches (_tkinter_pep3121-384_v0.patch and _tkinter_pep3121-384_v1.patch) seemed to have the refcounts right, but Andrew's further patches lost the required Py_INCREF in the various new() functions (and the corresponding Py_DECREF in deallocs), which is the cause for the crash in bpo-15667.
Activity
RobinSchreiber commentedon Aug 18, 2012
Changes proposed in PEP-3121 and PEP-384 have now been applied to the tkinter module!
When running the test form inside Python.exe (tkinter._test()), the litte "test-window" is rendered correctly. However there are still some error messages popping up inside the python shell
(I am running this on OS X 10.8):
I have no Idea how and where these are triggered.
loewis commentedon Aug 18, 2012
See
http://www.python.org/download/mac/tcltk/
It may be that using a different build of Tcl/Tk solves that problem.
ned-deily commentedon Aug 18, 2012
What version of 10.8 are you seeing those messages with? And do you see them without the patch applied?
asvetlov commentedon Oct 6, 2012
Update patch conforming to current _tkinter code.
asvetlov commentedon Oct 6, 2012
I would to have all module state inside _tkinterstate structure.
static variables like tcl_lock, tcl_state, quitMainLoop, errorInCmd etc should be moved into _tkinterstate also.
RobinSchreiber commentedon Oct 6, 2012
Before I submitted this patch, I used to have these variables inside the modulestate, which caused severe problems. I do not know the exact reason, but my guess is that these variables have to be globally available for every thread (tcl variables are used for thread synchronization arent they?). As the modulestate may change depending on the thread, one can no longer guarantee that every thread within the process is operating on the same variable. This might not be nessecary, however as I mentioned, the naive approach of putting the variables inside the modulestate did not work out for me.
asvetlov commentedon Oct 6, 2012
I'm trying to make patch following myself recommendations.
Looks good but not finished yet. Will publish it after all work done.
asvetlov commentedon Oct 6, 2012
Submit patch which store own state into module state.
Still not finished yet: need to add checks for "ready state" in every access to fields of module state structure.
asvetlov commentedon Oct 6, 2012
Update patch to support TKINTER_PROTECT_LOADTK option.
asvetlov commentedon Oct 6, 2012
Upload version which check if _tkinter module was destroyed (for example, if it was call from daemon thread runing Tk app when main thread is exiting with interpreter finalization).
asvetlov commentedon Oct 7, 2012
The patch for current default branch.
asvetlov commentedon Oct 7, 2012
The patch is huge, then I like to apply it in two steps: first implement PEP-384 than 3121.
Attached first patch.
python-dev commentedon Oct 14, 2012
New changeset bf9d118779f5 by Andrew Svetlov in branch 'default':
Issue bpo-15721: make _tkinter module PEP-384 compatible.
http://hg.python.org/cpython/rev/bf9d118779f5
amauryfa commentedon Oct 15, 2012
Andrew,
I have questions about the following part of commit bf9d118779f5:
+ PyTclObject_Type_slots[3].pfunc = PyObject_GenericGetAttr;
First, the "3" refers to the position of Py_tp_getattro in the array, which is a fragile thing IMO.
Then, this hack was not necessary before; why is it needed now?
IIRC on Windows a static initializer cannot contain dll-imported variables, but function pointers are OK.
Or do you have evidence of the contrary?
asvetlov commentedon Oct 15, 2012
Amaury, I completely agree with your objection.
I've found this code in xxlimited.c and adapted to _tkinter source.
If that weird code can be removed I will do it.
I have no idea how we can catch/reproduce the problem, maybe Martin von Loewis can help as author of xxlimited.c code?
As I know almost nobody make PEP-384 compliant modules for now and maybe there are couple of dark corners at least in the docs.
See also bpo-15650 for another question related to adaptation to PEP-3121.
asvetlov commentedon Oct 30, 2012
Amaury, you are right:
PyTclObject_Type_slots[3].pfunc = PyObject_GenericGetAttr;
is not required.
python-dev commentedon Oct 30, 2012
New changeset 4eb6e07e8171 by Andrew Svetlov in branch 'default':
Issue bpo-15721: apply PEP-384 Refactoring to tkinter module.
http://hg.python.org/cpython/rev/4eb6e07e8171
BreamoreBoy commentedon Apr 18, 2013
Is any more work needed on this issue or can it be closed?
asvetlov commentedon Apr 19, 2013
No, PEP-3121 patch is not ready yet but PEP-384 has been applied.
pitrou commentedon Aug 10, 2013
The first two patches (_tkinter_pep3121-384_v0.patch and _tkinter_pep3121-384_v1.patch) seemed to have the refcounts right, but Andrew's further patches lost the required Py_INCREF in the various new() functions (and the corresponding Py_DECREF in deallocs), which is the cause for the crash in bpo-15667.
python-dev commentedon Aug 10, 2013
New changeset 4d0c938870bc by Antoine Pitrou in branch 'default':
Fix refcounting issue with extension types in tkinter.
http://hg.python.org/cpython/rev/4d0c938870bc
serhiy-storchaka commentedon Nov 26, 2014
_tkinter classes are now heap types and they no longer have the __module__ attribute.
See bpo-20204.
serhiy-storchaka commentedon Nov 15, 2015
This change causes a crash when create instances of _tkinter classes (bpo-23815). If this will not be fixed I suggest to revert the patch.
serhiy-storchaka commentedon May 8, 2016
Fixed in bpo-23815. Opened bpo-26979 for documenting the catch.