Somewhere along the way, math.log gained an optional "base" argument. cmath.log is still missing it. >>> print math.log.__doc__ log(x[, base]) -> the logarithm of x to the given base. If the base not specified, returns the natural logarithm (base e) of x. >>> print cmath.log.__doc__ log(x) Return the natural logarithm of x.
Logged In: YES user_id=80475 I can fix this if necessary. My question is whether it should be done. On the one hand, it is nice to have the two interfaces as symmetrical as possible. OTOH, I'm not aware of any use cases for log(z, b).
Logged In: YES user_id=99508 In my particular usecase, I define an environment in which people can execute mathematical statements like so: _mathEnv = {'__builtins__': new.module('__builtins__'), 'i': 1j} _mathEnv.update(math.__dict__) _mathEnv.update(cmath.__dict__) As you can see, the cmath definitions shadow the math definitions, and thus I lose the useful ability to offer users a log with a base (which those that know Python expect to work). That's at least my particular use case. In this particular instance, since I don't want to allow the users to cause the application to consume arbitrary amounts of memory, I can't allow integer arithmetic (because of the crazy int/long unification that left people who wanted computationall bounded arithmetic with no choice but to implement a fixed-size integer type or use float/complex instead ;)) so I use complex objects everywhere, and math.log can't operate on complex objects (even those that have no imaginary component).
