[Python-Dev] python-dev summary for 2006-08-01 to 2006-08-15 (original) (raw)

Steven Bethard steven.bethard at gmail.com
Tue Sep 26 06:04:37 CEST 2006

Sorry about the delay. Here's the summary for the first half of August. As always, comments and corrections are greatly appreciated.

========= Summaries

Mixing str and unicode dict keys

Ralf Schmitt noted that in Python head, inserting str and unicode keys to the same dictionary would sometimes raise UnicodeDecodeErrors::

>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
Traceback (most recent call last):
  ...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in

position 1: ordinal not in range(128)

This error showed up as a result of Armin Rigo's patch to stop dict lookup from hiding exceptions_, which meant that the UnicodeDecodeError raised when a str object is compared to a non-ASCII unicode object was no longer silenced. In the end, people agreed that UnicodeDecodeError should not be raised for equality comparisons, and in general, __eq__() methods should not raise exceptions. But comparing str and unicode objects is often a programming error, so in addition to just returning False, equality comparisons on str and non-ASCII unicode now issues a warning with the UnicodeDecodeError message.

.. _patch to stop dict lookup from hiding exceptions: http://bugs.python.org/1497053

Contributing threads:

Rounding floats to ints

Bob Ippolito pointed out a long-standing bug in the struct module where floats were automatically converted to ints. Michael Urman showed a simple case that would provoke an exception if the bug were fixed::

pack('>H', round(value * 32768))

The source of this bug is the expectation that round() returns an int, when it actually returns a float. There was then some discussion about splitting the round functionality into two functions: __builtin__.round() which would round floats to ints, and math.round() which would round floats to floats. There was also some discussion about the optional argument to round() which currently specifies the number of decimal places to round to -- a number of folks felt that it was a mistake to round to decimal places when a float can only truly reflect binary places.

In the end, there were no definite conclusions about the future of round(), but it seemed like the discussion might be resumed on the Python 3000 list.

Contributing threads:

Assigning to function calls

Neal Becker proposed that code by X() += 2 be allowed so that you could call iadd on objects immediately after creation. People pointed out that allowing augmented assignment is misleading when no assignment can occur, and it would be better just to call the method directly, e.g. X().__iadd__(2).

Contributing threads:

PEP 357: Integer clipping and index

After some further discussion on the __index__ issue_ of last fortnight, Travis E. Oliphant proposed a patch for __index___ that introduced three new C API functions:

After a few minor edits, this patch was checked in.

.. index issue: http://www.python.org/dev/summary/2006-07-16_2006-07-31/#pep-357-integer-clipping-and-index .. a patch for index: http://bugs.python.org/1538606

Contributing threads:

OpenSSL and Windows binaries

Jim Jewett pointed out that a default build of OpenSSL includes the patented IDEA cipher, and asked whether that needed to be kept out of the Windows binary versions. There was some concern about dropping a feature, but Gregory P. Smith pointed out that IDEA isn't directly exposed to any Python user, and suggested that IDEA should never be required by any sane SSL connection. Martin v. Löwis promised to look into making the change.

Contributing threads:

Type of range object members

Alexander Belopolsky proposed making the members of the range() object use Py_ssize_t instead of C longs. Guido indicated that this was basically wasted effort -- in the long run, the members should be PyObject* so that they can handle Python longs correctly, so converting them to Py_ssize_t would be an intermediate step that wouldn't help in the transition.

There was then some discussion about the int and long types in Python 3000, with Guido suggesting two separate implementations that would be mostly hidden at the Python level.

Contributing thread:

Distutils version number

A user noted that Python 2.4.3 shipped with distutils 2.4.1 and the version number of distutils in the repository was only 2.4.0 and requested that Python 2.5 include the newer distutils. In fact, the newest distutils was already the one in the repository but the version number had not been appropriately bumped. For a short while, the distutils number was automatically generated from the Python one, but Marc-Andre Lemburg volunteered to manually bump it so that it would be easier to use the SVN distutils with a different Python version.

Contributing threads:

Dict containment and unhashable items

tomer filiba suggested that dict.contain should return False instead of raising a TypeError in situations like::

>>> a={1:2, 3:4}
>>> [] in a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: list objects are unhashable

Guido suggested that swallowing the TypeError here would be a mistake as it would also swallow any TypeErrors produced by faulty __hash__() methods.

Contributing threads:

Returning longs from hash()

Armin Rigo pointed out that Python 2.5's change that allows id() to return ints or longs would have caused some breakage for custom hash functions like::

def __hash__(self):
    return id(self)

Though it has long been documented that the result of id() is not suitable as a hash value, code like this is apparently common. So Martin v. Löwis and Armin arranged for PyLong_Type.tp_hash to be called in the code for hash().

Contributing thread:

instancemethod builtin

Nick Coghlan suggested adding an instancemethod() builtin along the lines of staticmethod() and classmethod() which would allow arbitrary callables to act more like functions. In particular, Nick was considering code like::

class C(object):
    method = some_callable

Currently, if some_callable did not define the __get__() method, C().method would not bind the C instance as the first argument. By introducing instancemethod(), this problem could be solved like::

class C(object):
    method = instancemethod(some_callable)

There wasn't much of a reaction one way or another, so it looked like the idea would at least temporarily be shelved.

Contributing thread:

Unicode versions and unicodedata

Armin Ronacher noted that Python 2.5 implements Unicode 4.1 but while a ucd_3_2_0 object is available (implementing Unicode 3.2), no ucd_4_1_0 object is available. Martin v. Löwis explained that the ucd_3_2_0 object is only available because IDNA needs it, and that there are no current plans to expose any other Unicode versions (and that ucd_3_2_0 may go away when IDNA no longer needs it).

Contributing thread:

================== Previous Summaries

=============== Skipped Threads

More information about the Python-Dev mailing list