In 2.7 and 3.3:>>> import _tkinter>>> _tkinter.Tcl_Obj()Traceback (most recent call last):  File "<stdin>", line 1, in <module>TypeError: cannot create '_tkinter.Tcl_Obj' instances>>> _tkinter.TkttType()Traceback (most recent call last):  File "<stdin>", line 1, in <module>TypeError: cannot create 'tktimertoken' instancesIn 3.4+:>>> import _tkinter>>> _tkinter.Tcl_Obj()Segmentation fault (core dumped)And the same for _tkinter.TkttType.Looks as this is a result ofissue15721.

With 3.4.3, I get the equivalent on Windows (a 'python has stopped working' box).

Probably a PyType_Ready() missing.

PyType_Ready() is called inside PyType_FromSpec().

Beforeissue15721 the tp_new was NULL, and this prevented from creating instances. Afterissue15721 the tp_new is inherited from object. An instance is created, but all internal pointers are NULLs. Following repr() dereferences NULL.

There is special exception -- tp_new is not inherited for static types whose base class is 'object' (see a comment in inherit_special() inObjects/typeobject.c#4569 for explanation). After converting them to heap types they became inherit tp_new from object.Proposed patch adds workarounds for types in _tkinter and curses.panel modules.

The news part of the patch did not apply  -- best not to include such in posted patches.After recompiliing 3.5 on Windows 10, the two tkinter test cases give the 3.3 TypeErrors instead of crashing.  test_tcl also runs.  curses does not run on Windows.I do not know enough internals to really understand#15721 or why you call the fix a workaround, but I do understand 'exception' (OK) versus 'crash' (forbidden).  Unless you think restoring the previous situation (tp_new = NUll) can cause a worse problem, I would apply this soon, within a week, so not forgotten before the June update releases.  The tcl test addition is correct.  The fix can be improved later if you think of something better.I initially wondered why _tkinter has classes that cannot be instantiated (from Python).  Then I discovered that this is normal, and that the exception is standard.>>> type(iter([]))()Traceback (most recent call last):  File "<stdin>", line 1, in <module>TypeError: cannot create 'list_iterator' instancesIs list_iterator.tp_new NULL?  Or does it raise instead of crash by other means?

I called the fix a workaround because other solution may be to make PyType_FromSpec() not setting tp_new in such cases. I expect that this is common mistake when convert a static class to a heap class with PyType_FromSpec(). At least we should add warnings in C API documentation andPEP 384. Or change the behavior of PyType_FromSpec() if it is appropriate. But this is different issue. If PyType_FromSpec() will be changed, proposed fix can be reverted.

I noticed that you reported the crash and asked for a fix or reversion on#15721 6 months ago, with no response.  Hence, lets not wait longer.Looking again, I see that there were 3 rounds of patches in 2012/2013.  If you want to follow up, I suggest closing that issue and open a fresh issue with with alternatives and your recommendation.

New changesetcd25508c62fc by Serhiy Storchaka in branch '3.5':Issue#23815: Fixed crashes related to directly created instances of types inhttps://hg.python.org/cpython/rev/cd25508c62fcNew changeset1c6326e81c33 by Serhiy Storchaka in branch 'default':Issue#23815: Fixed crashes related to directly created instances of types inhttps://hg.python.org/cpython/rev/1c6326e81c33

After looking closer I found that making PyType_FromSpec() not inheriting tp_new for static types whose base class is 'object' is not an option, because this breaks examples in the documentation, and likely break some third-party code. Opened newissue26979 for documenting the catch.Thank you for your review Terry.