On Sun, Dec 28, 2008 at 5:09 AM, Nick Coghlan <ncogh...@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 _______________________________________________ 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
