More words on patch #837242, since 4 or 5 tests started
failing on one of the 32-bit buildbot boxes because of it, due to tempting but always-wrong Python code. Users probably have code like this too (I know I did ...).
This commit is contained in:
parent
51dd7d9719
commit
3a5e8b1e36
17
Misc/NEWS
17
Misc/NEWS
|
@ -12,9 +12,20 @@ What's New in Python 2.5 alpha 2?
|
|||
Core and builtins
|
||||
-----------------
|
||||
|
||||
- Patch #837242: id() of any Python object always gives a positive
|
||||
number, which might be a long integer. PyLong_FromVoidPtr and
|
||||
PyLong_AsVoidPtr have been changed accordingly.
|
||||
- Patch #837242: ``id()`` of any Python object always gives a positive
|
||||
number now, which might be a long integer. ``PyLong_FromVoidPtr`` and
|
||||
``PyLong_AsVoidPtr`` have been changed accordingly. Note that it has
|
||||
never been correct to implement a ``hash()`` method that returns the
|
||||
``id()`` of an object:
|
||||
|
||||
def __hash__(self):
|
||||
return id(self) # WRONG
|
||||
|
||||
because a hash result must be a (short) Python int but it was always
|
||||
possible for ``id()`` to return a Python long. However, because ``id()``
|
||||
cuold return negative values before, on a 32-bit box an ``id()`` result
|
||||
was always usable as a hash value before this patch. That's no longer
|
||||
necessarily so.
|
||||
|
||||
- Python on OS X 10.3 and above now uses dlopen() (via dynload_shlib.c)
|
||||
to load extension modules and now provides the dl module. As a result,
|
||||
|
|
Loading…
Reference in New Issue