Yes, I much prefer the reassurance of immutability. In Java, it also lets you use the "==" operator instead of the equals(...) method; I wonder if that is another bit of awkwardness that Python does away with. I hope so.

I add my yet-feeble voice to the call for Money, or the more generic FixedPoint, to be added to a standard library. Rewriting that stuff is getting boring.

I must find out what Python does about time points; I am always writing Java code to represent time at various levels of granularity.

Ah, dates and times.

Well, up until Python 2.2, everyone used mxDateTime - see http://www.egenix.com/files/python/mxDateTime.html . But a new datetime module was added in 2.3 - http://www.python.org/doc/2.3/whatsnew/node18.html .

I'll be sticking with mxDateTime myself, partly 'cos it has more functionality (see http://www.brunningonline.net/simon/blog/archives/000868.html ), partly 'cos I don't want to change working code, and partly 'cos Python 2.2 is installed on about a million machines around my company, and I won't be able to upgrade them all for some time.

But you should look at both - if the standard library module does what you need, then that's one less dependency for you to worry about.

To address your other points, identity and equality are not the same thing in Python, just like in Java. But in Python, == checks for equality, and 'is' checks for identity. I think that's less awkward ;-)

One of the nicest things about Python is that you can experiment with this sort of thing interactively:

>>> import FixedPoint
>>> foo = FixedPoint.FixedPoint("1.10")
>>> bar = FixedPoint.FixedPoint("1.10")
>>> foo == bar
1
>>> foo is bar
0

So, foo and bar are equal, but since they are different objects, they are not identical.

Identity is funny in Python, though. Look at this:

>>> foo = 1
>>> bar = 1
>>> foo == bar
1
>>> foo is bar
1
>>> foo = 1234
>>> bar = 1234
>>> foo == bar
1
>>> foo is bar
0

The discrepancy here is due to the fact that Python can 'intern' objects, i.e. use a single object for all equal values. Currently, Python does this for integers up to (IIRC) 99, and all strings which look like identifiers. You can't rely on this behaviour, though - it's an implementation detail, and could change from release to release. (Not that I can think of any reason why you'd *want* to rely on it...)

To interject, the reason Python's installed on about 9 pc's in our office is just coz of SB's evangelism; Good or Bad, you decide.....

Python evangelist, and proud of it. ;-)

""" Identity is funny in Python, though. [...] The discrepancy here is due to the fact that Python can 'intern' objects, i.e. to use a single object for all equal values. Currently, Python does this for integers up to (IIRC) 99, and all strings which look like identifiers. You can't rely on this behaviour, though - it's an implementation detail, and could change from release to release. (Not that I can think of any reason why you'd *want* to rely on it...)"""

Me neither. ;-) Identity really shouldn't matter for immutable objects, should it?

Python 2.4 will contain an implementation of IBM's proposed standard for decimal arithmetic:

http://www2.hursley.ibm.com/decimal/

So far it's a pure-Python module, and can be dropped into 2.3.4. There's no other decimal module even worth a glance anymore (and I stopped looking at FixedPoint a couple years ago, to devote what time I could volunteer for this stuff to pushing the IBM standard along).

To install decimal.py in 2.3.x, download the package at http://sourceforge.net/projects/sigefi.

Thabks, Facundo. Me: I'll be upgrading to 2.4 ASAP, though. ;-)

very interesting, but I don't agree with you
Idetrorce