python-dev Summary for 2006-08-01 through 2006-08-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++
.. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-08-01_2006-08-15] ========= 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: - `unicode hell/mixing str and unicode as dictionary keys <http://mail.python.org/pipermail/python-dev/2006-August/067926.html>`__ - `Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys <http://mail.python.org/pipermail/python-dev/2006-August/067978.html>`__ - `Dicts are broken ... <http://mail.python.org/pipermail/python-dev/2006-August/067992.html>`__ - `Dict suppressing exceptions <http://mail.python.org/pipermail/python-dev/2006-August/068090.html>`__ ----------------------- 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: - `struct module and coercing floats to integers <http://mail.python.org/pipermail/python-dev/2006-July/067798.html>`__ - `Rounding float to int directly (Re: struct module and coercing floats to integers) <http://mail.python.org/pipermail/python-dev/2006-July/067819.html>`__ - `Rounding float to int directly (Re: struct module and coercing floats to integers) <http://mail.python.org/pipermail/python-dev/2006-August/067867.html>`__ - `Rounding float to int directly ... <http://mail.python.org/pipermail/python-dev/2006-August/067873.html>`__ - `struct module and coercing floats to integers <http://mail.python.org/pipermail/python-dev/2006-August/067911.html>`__ --------------------------- 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: - `SyntaxError: can't assign to function call <http://mail.python.org/pipermail/python-dev/2006-August/068081.html>`__ - `Split augmented assignment into two operator sets? [Re: SyntaxError: can't assign to function call] <http://mail.python.org/pipermail/python-dev/2006-August/068148.html>`__ --------------------------------------- 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: * PyIndex_Check(obj) -- checks for nb_index * PyObject* PyNumber_Index(obj) -- calls nb_index if possible or raises a TypeError * Py_ssize_t PyNumber_AsSsize_t(obj, err) -- converts the object to a Py_ssize_t, raising err on overflow 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: - `Bad interaction of __index__ and sequence repeat <http://mail.python.org/pipermail/python-dev/2006-August/067870.html>`__ - `__index__ clipping <http://mail.python.org/pipermail/python-dev/2006-August/068091.html>`__ - `Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c Modules/operator.c Objects/abstract.c Objects/classobject.c Objects/ <http://mail.python.org/pipermail/python-dev/2006-August/068204.html>`__ - `Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c Modules/operator.c Objects/abstract.c Objects/class <http://mail.python.org/pipermail/python-dev/2006-August/068209.html>`__ ---------------------------- 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. Lowis promised to look into making the change. Update: The change was checked in before 2.5 was released. Contributing threads: - `windows 2.5 build: use OpenSSL for hashlib [bug 1535502] <http://mail.python.org/pipermail/python-dev/2006-August/068009.html>`__ - `openSSL and windows binaries - license <http://mail.python.org/pipermail/python-dev/2006-August/068055.html>`__ ---------------------------- 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: - `Type of range object members <http://mail.python.org/pipermail/python-dev/2006-August/068230.html>`__ ------------------------ 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: - `Which version of distutils to ship with Python 2.5? <http://mail.python.org/pipermail/python-dev/2006-August/067869.html>`__ - `no remaining issues blocking 2.5 release <http://mail.python.org/pipermail/python-dev/2006-August/068240.html>`__ ------------------------------------- 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: - `dict containment annoyance <http://mail.python.org/pipermail/python-dev/2006-August/068198.html>`__ - `NotHashableError? (Re: dict containment annoyance) <http://mail.python.org/pipermail/python-dev/2006-August/068218.html>`__ ------------------------------- 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. Lowis and Armin arranged for ``PyLong_Type.tp_hash`` to be called in the code for ``hash()``. Contributing thread: - `returning longs from __hash__() <http://mail.python.org/pipermail/python-dev/2006-August/068043.html>`__ ---------------------- 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: - `2.6 idea: a 'function' builtin to parallel classmethod and staticmethod <http://mail.python.org/pipermail/python-dev/2006-August/068189.html>`__ -------------------------------- 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. Lowis 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: - `Unicode Data in Python2.5 is missing a ucd_4_1_0 object <http://mail.python.org/pipermail/python-dev/2006-August/068126.html>`__ -------------------------- Elementtree and Namespaces -------------------------- Elements (and attributes) can be associated with a namespace, such as http://www.w3.org/XML/1998/namespace:id The xmlns attribute creates a "prefix" (alias) for a namespace, so that you can abbreviate the above as xml:id ElementTree treats the prefix as a just an aid to human readers, and creates its own abbreviations that are consistent throughout a document. Some tools (including w3 recommendations for canonicalization) treat the prefix itself as meaningful. Elementtree may support this in version 1.3, but it wasn't going to be there in time for 2.5, and it wasn't judged important enough to keep etree out of the release. If you need it sooner, then http://codespeak.net/lxml supports the etree API and does retain prefixes. Contributing thread: - `Elementtree and Namespaces in 2.5 <http://mail.python.org/pipermail/python-dev/2006-August/068171.html>`__ [Thanks to Jim Jewett for this summary.] ================== Previous Summaries ================== - `Release manager pronouncement needed: PEP 302 Fix <http://mail.python.org/pipermail/python-dev/2006-August/068050.html>`__ =============== Skipped Threads =============== - `clock_gettime() vs. gettimeofday()? <http://mail.python.org/pipermail/python-dev/2006-August/067879.html>`__ - `Strange memo behavior from cPickle <http://mail.python.org/pipermail/python-dev/2006-August/067881.html>`__ - `internal weakref API should be Py_ssize_t? <http://mail.python.org/pipermail/python-dev/2006-August/067885.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-August/067888.html>`__ - `Releasemanager, please approve #1532975 <http://mail.python.org/pipermail/python-dev/2006-August/067889.html>`__ - `FW: using globals <http://mail.python.org/pipermail/python-dev/2006-August/067892.html>`__ - `TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3 <http://mail.python.org/pipermail/python-dev/2006-August/067898.html>`__ - `segmentation fault in Python 2.5b3 (trunk:51066) <http://mail.python.org/pipermail/python-dev/2006-August/067921.html>`__ - `using globals <http://mail.python.org/pipermail/python-dev/2006-August/067947.html>`__ - `uuid module - byte order issue <http://mail.python.org/pipermail/python-dev/2006-August/067948.html>`__ - `RELEASED Python 2.5 (beta 3) <http://mail.python.org/pipermail/python-dev/2006-August/067959.html>`__ - `TRUNK is UNFROZEN <http://mail.python.org/pipermail/python-dev/2006-August/067961.html>`__ - `2.5 status <http://mail.python.org/pipermail/python-dev/2006-August/067963.html>`__ - `Python 2.5b3 and AIX 4.3 - It Works <http://mail.python.org/pipermail/python-dev/2006-August/067985.html>`__ - `More tracker demos online <http://mail.python.org/pipermail/python-dev/2006-August/067996.html>`__ - `need an SSH key removed <http://mail.python.org/pipermail/python-dev/2006-August/067999.html>`__ - `BZ2File.writelines should raise more meaningful exceptions <http://mail.python.org/pipermail/python-dev/2006-August/068005.html>`__ - `test_mailbox on Cygwin <http://mail.python.org/pipermail/python-dev/2006-August/068006.html>`__ - `cgi.FieldStorage DOS (sf bug #1112549) <http://mail.python.org/pipermail/python-dev/2006-August/068011.html>`__ - `2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post) <http://mail.python.org/pipermail/python-dev/2006-August/068012.html>`__ - `free(): invalid pointer <http://mail.python.org/pipermail/python-dev/2006-August/068042.html>`__ - `should i put this on the bug tracker ? <http://mail.python.org/pipermail/python-dev/2006-August/068045.html>`__ - `Is this a bug? <http://mail.python.org/pipermail/python-dev/2006-August/068076.html>`__ - `httplib and bad response chunking <http://mail.python.org/pipermail/python-dev/2006-August/068087.html>`__ - `cgi DoS attack <http://mail.python.org/pipermail/python-dev/2006-August/068092.html>`__ - `DRAFT: python-dev summary for 2006-07-01 to 2006-07-15 <http://mail.python.org/pipermail/python-dev/2006-August/068098.html>`__ - `SimpleXMLWriter missing from elementtree <http://mail.python.org/pipermail/python-dev/2006-August/068106.html>`__ - `DRAFT: python-dev summary for 2006-07-16 to 2006-07-31 <http://mail.python.org/pipermail/python-dev/2006-August/068136.html>`__ - `Is module clearing still necessary? [Re: Is this a bug?] <http://mail.python.org/pipermail/python-dev/2006-August/068146.html>`__ - `PyThreadState_SetAsyncExc bug? <http://mail.python.org/pipermail/python-dev/2006-August/068158.html>`__ - `Errors after running make test <http://mail.python.org/pipermail/python-dev/2006-August/068176.html>`__ - `What is the status of file.readinto? <http://mail.python.org/pipermail/python-dev/2006-August/068188.html>`__ - `Recent logging spew <http://mail.python.org/pipermail/python-dev/2006-August/068196.html>`__ - `[Python-3000] Python 2.5 release schedule (was: threading, part 2) <http://mail.python.org/pipermail/python-dev/2006-August/068199.html>`__ - `test_socketserver failure on cygwin <http://mail.python.org/pipermail/python-dev/2006-August/068216.html>`__ - `ANN: byteplay - a bytecode assembler/disassembler <http://mail.python.org/pipermail/python-dev/2006-August/068225.html>`__ - `Arlington VA sprint on Sept. 23 <http://mail.python.org/pipermail/python-dev/2006-August/068226.html>`__ - `IDLE patches - bugfix or not? <http://mail.python.org/pipermail/python-dev/2006-August/068266.html>`__ - `Four issue trackers submitted for Infrastructue Committee's tracker search <http://mail.python.org/pipermail/python-dev/2006-August/068287.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from August 01, 2006 through August 15, 2006. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This python-dev summary is the 10th written by Steve Bethard. To contact me, please send email: - Steve Bethard (steven.bethard at gmail.com) Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! ------------------------- How to Read the Summaries ------------------------- This summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _Python Software Foundation: http://python.org/psf/ .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
