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) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
