On Sun, Dec 28, 2008 at 5:09 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Nick Coghlan wrote:
Nick Coghlan wrote:
Is there a specific reason for not fully initialising the builtin types? Or should we be calling PyType_Ready on each of them from _PyBuiltin_Init?
I need to correct this slightly: some builtin types *are* initialised properly by _Py_ReadyTypes.
So the question is actually whether or not the missing builtin types should be added to that function.
I'm probably going to fix the specific problem with hashing of range objects in Py3k just by initialising xrange/range properly in _Py_ReadyTypes.
However, I wonder how many other builtin types have the same problem - for example, the enumerate type is also missing a call to PyType_Ready:
Python 3.1a0 (py3k, Dec 14 2008, 21:35:11) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
x = enumerate([]) hash(x) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unhashable type: 'enumerate' enumerate.__name__ # implicit call to PyType_Ready 'enumerate' hash(x) -1212398692
Rather than playing whack-a-mole with this, does anyone have any ideas on how to systematically find types which are defined in the core, but are missing an explicit PyType_Ready call? (I guess one way would be to remove all the implicit calls in a local build and see what blows up... that seems a little drastic though)
What I did with safethread was replace the implicit calls with assertions. That with the test suite should pick everything up. -- Adam Olsen, aka Rhamphoryncus