dcsimg
Linux Today: Linux News On Internet Time.




More on LinuxToday


Python-dev summary: October 1-16, 2000

Oct 22, 2000, 16:38 (0 Talkback[s])
(Other stories by A.M. Kuchling)

WEBINAR:
On-Demand

Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers


Date: Fri, 20 Oct 2000 20:58:16 -0400
From: A.M. Kuchling amk@mira.erols.com
To: python-announce@python.org
Subject: Python-dev summary: Oct 1-16

Python-dev summary, October 1-16, 2000


(To comment on material in this python-dev summary, you can simply post to comp.lang.python / python-list@python.org.)

Released at last!


Python 2.0final was released on October 16, doubtless as a late birthday gift for me:
ftp://ftp.python.org/pub/python/src/python-2.0.tar.gz

Python 2.1


The python-dev traffic in the two weeks leading up to that announcement continued to be primarily focused on particular small bugs and how to fix them. Now that 2.0 is out, though, the CVS tree will be reopened for larger changes:
http://www.python.org/pipermail/python-dev/2000-October/016694.html

It's important to note that this doesn't mean people can check in any changes they like. Large changes must still be first written up as a PEP and get approved by the community. Jeremy Hylton is responsible for PEP 226, which will track the release schedule for Python 2.1 Currently the schedule calls for a beta in February 2001 and a final release in March, but this is certain to change.
http://python.sourceforge.net/peps/pep-0226.html

Python and floating point


The largest thread that arose in this time span was about Python's support for floating point, and the discussion spread out across 3 different mailing lists before it was over. It all started with a seemingly minor bug report, when Huaiyu Zhu pointed out that math.exp(-746) returns 0.0 in Python 1.5.2, but raises an OverflowError in 2.0b2:
http://www.python.org/pipermail/python-list/2000-October/120732.html

This is surprising, because e^(-746) would really be an underflow, not an overflow. The change turned out to be caused by the Python binary no longer linking with -lieee on Linux, and a patch was committed before 2.0final to change the behaviour for this one case, but this is just a small manifestation of a much wider problem, namely that Python lacks IEEE 754 floating point semantics. IEEE 754 is a specification that carefully nails down a set of behaviours for binary floating point operations.

Python lacks IEEE 754 semantics because nothing in the C89 or POSIX standards provides a portable way to request them. Tim Peters: "There's no bug here, in the strong sense that no documented (or even intended!) behavior has changed. What happened is that one platform accident got changed to a different platform accident. You certainly get sympathy for that, but not enough to buy radical last-minute changes."
http://www.python.org/pipermail/python-dev/2000-October/016566.html

The discussion then continued for a long while, with the bulk of the argument between Huaiyu and Tim. Huaiyu said that Python 2.0's behaviour should be changed in a few ways, and Tim argued that any fix would merely change the current unpredictable and nonportable behaviour to some other unpredictable and nonportable behaviour, and that making changes a few days before the final release of 2.0 was a bad idea in any event. It was pleasing to see that, though Huaiyu and Tim occasionally got quite short with each other, the tone remained that of a contentious technical discussion and not a flamewar.

IEEE 754 lets the programmer specify different modes for handling errors and for rounding. For example, the programmer can select whether division by zero triggers a IEEE 754 exception, returns NaN (Not a Number) or Inf (infinity), or returns some other arbitrary value (0, pi, 187.42).

Different programs will want different behaviours. For example, Steven D. Majewski usually wants the calculation to continue despite an error: "I do a lot of vectorized operations on what are often independent samples. If some of the numbers overflow or underflow, that just represents an outlier or bad sample. I don't want it to blow off the whole pipeline of operations on the other data points -- they are independent of the bad points."
http://www.python.org/pipermail/python-dev/2000-October/016597.html

On the other hand, Paul Dubois wrote: "Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to stop, not put a zero and keep going."
http://www.python.org/pipermail/python-dev/2000-October/016593.html

Clearly, flexibility on this point is required.

Huaiyu even wrote Prof. William Kahan, the strongest advocate for IEEE 754 and one of the authors of the standard. Kahan's response is packed with information from an expert, and is well worth reading. "The programmer is the only one competent to decide which exceptions his program can ignore, which to allow to pass on to detection later, which to trap if they must. ... 'Interim steps' have a tendency to become permanent in our industry, where 'Compatibility' is the way the sins of the fathers are inflicted upon the third and fourth generations."
http://www.python.org/pipermail/python-list/2000-October/143284.html
http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html
http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html

C89 and POSIX say nothing about IEEE 754. The more recent C99 standard *does* specify ways to set IEEE 754 behaviour, which means that as gcc+glibc and platform compilers move to support C99, Python can finally implement it portably. However, C99 is no magic bullet, and there will still be tricky problems to solve. For example, how will 754 interact with threads? Can one thread set Infs as the return value for errors while another thread runs a trap handler in the event of an error?

So, while the particular error reported was fixed for 2.0, but the question of IEEE 754 support for Python remains open; it's not something you can implement in a week. It seems likely that someone, perhaps Kevin Jacobs, will write a PEP for 2.1 suggesting a way to add 754 support:
http://www.python.org/pipermail/python-list/2000-October/143294.html

Buffer objects


Mark Hammond pointed out an apparent oddity in the behaviour of buffer objects and the + operator: "Adding 2 buffer objects together yields a string. Fair enough. Adding a buffer and a string yields a type error! Eeek."
http://www.python.org/pipermail/python-dev/2000-October/016675.html

Greg Stein, who originally suggested and implemented the buffer object, pointed out that this was unavoidable: "It is caused by the non-commutative aspect of Python types. You end up with a string, and that type doesn't know how to add a buffer to itself."
http://www.python.org/pipermail/python-dev/2000-October/016682.html

Guido expressed his misgivings about the buffer interface: "The buffer interface is one of the most misunderstood parts of Python. I believe that if it were PEPped today, it would have a hard time getting accepted in its current form."
http://www.python.org/pipermail/python-dev/2000-October/016685.html

Greg Stein responded, saying the problems are fixable: "Many of the issues with the buffer object can be solved with simple changes."
http://www.python.org/pipermail/python-dev/2000-October/016699.html

Jeff Collins also pointed out that buffer objects are very useful for conserving memory for the PalmOS port: "Directly referencing the data of objects like bytecodes and strings would greatly reduce the dynamic heap (current limit of 256K on PalmOS 3.5 on devices with 4M RAM or greater) requirements."
http://www.python.org/pipermail/python-dev/2000-October/016691.html

Other matters


Greg Ward announced that the Distutils have reached version 1.0:
http://www.python.org/pipermail/python-dev/2000-October/016445.html

Jeremy Hylton discovered that one portion of the Distutils, the actual binary used for generating Windows installers, didn't have its source available in the Python CVS tree, only in the Distutils CVS tree. Thomas Heller explained: "bdist_wininst creates a self-extracting zipfile from two components: a stub program (wininst.exe) plus a zip-file containing the code to be distributed. Because I did not liked wininst.exe as binary file checked into CVS, the actual bytes of this exe are included base64-encoded in the bdist_wininst.py module as string. I'm not sure whether this is a wise design or not, but that is a different topic."
http://www.python.org/pipermail/python-dev/2000-October/016540.html

Related Links


Python-dev archives:
http://www.python.org/pipermail/python-dev/

Python project page on SourceForge:
http://sourceforge.net/projects/python

Python Enhancement Proposals (PEPs):
http://python.sourceforge.net/peps/

What's New in Python 2.0:
http://starship.python.net/crew/amk/python/writing/new-python/