On Sun, Dec 28, 2008 at 5:09 AM, Nick Coghlan <ncoghlan at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4