Speed *triples* by changing 'apply(f, args)' to 'f(*args)'

[Tim Peters]

>> ... because the apply() builtin is deprecated now, the implementation
>> of __builtin__.apply() now calls warnings.warn() (a Python function)
>> to see whether it should issue a deprecation warning.  So the former
>> also costs a new hidden call to a long Python function now, which in
>> turn does many lookups and additional calls (both C and Python
>> level) of its own. ...

[Aahz]
> Ouch.  Should we consider postponing the official deprecation of apply()
> for one more release?  I'm concerned about the possible speed of the
> logging module.

I doubt anyone calls a logging function in the innermost loop of a
time-critical region (whereas Gerritt called apply() in a time-critical
region of his program), so, no, I'm not concerned.  Postponing deprecation
wouldn't do the logging module any good anyway, as its author wants to keep
it backward compatible (i.e., delay deprecation until 2.4, and in 2.4 the
logging module will still be using apply()).  Finally, in the unlikely case
logging is a real time sink in 2.3 because of its use of apply(), in 2.3.1
(or in 2.3 final if it's discovered by alpha or beta testers), we *could*
stop calling apply() in it right now.