[Numpy-discussion] Deprecation of financial routines

[Joe Harrington]

> On 8/19/2013 2:37 AM, Juan Luis Cano wrote:
>> https://github.com/numpy/numpy/issues/2880
>>
>> it was suggested that we deprecate and eventually remove the financial
>> functions in NumPy

IDL has financial functions.  Matlab has financial functions.  Financial
functions are something that a subset of potential customers of
numerical packages look for.  There is a strong tradition of people
going from math/science/engineering into the finanical world, and people
start on that route by playing with strategies and seeing what they can
do relative to the market.  To see how well they do, they need to
calculate an internal rate of return, and so forth.

The fin routines are tiny and don't require much maintenance once
written.  If we made an effort (putting up pages with examples of common
financial calculations and collecting those under a topical web page,
then linking to that page from various places and talking it up), I
would think they could attract users looking for a free way to play with
financial scenarios.  Python is a perfect language for newbies to
programming, which many who want to play with finances are.

So, I would say we keep them.  If ours are not the best, we should bring
them up to snuff.

I think we can endlessly debate namespace pollution.  Developers hate
it, but most normal users just don't mind a large number of routines in
the top level, and many actively dislike the code litter of lots of
long, dotted routine names.  I've had a hard time getting my colleagues
not to "from numpy import *".  Some of the good ones even teach that in
their seminars to convert IDL and IRAF users, and they chew me out when
I suggest to them that it's a bad habit!

A reorg that would bring us to a very heirarchical structure would be
disruptive to existing code.  Yet, there are maintenance and startup
speed arguments in favor of a heirarchy.  However we resolve it, I don't
know that singling out the financial routines is the right short-term
approach, and it wouldn't make much of a dent.  So, I'd suggest we take
it as two issues to solve separately 1) keeping or tossing the fin
routines and 2) moving toward a heirarchy of routines or not.

I'm -1 for deprecating the routines.

I'll hold off on the second question until someone makes a clear
proposal that resolves namespace pollution, and we discuss it.

--jh--