Re: [Numpy-discussion] Deprecation of financial routines
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--
[snip] On 08/19/2013 05:06 PM, Joe Harrington wrote:
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.
Talking about existing code, honestly I don't think we should worry about that much. I made a not-so-shallow search on GitHub and Google and I saw zero mention of numpy.financial in the NumPy User Guide, zero in the SciPy Cookbook, no mention on GitHub (people are pushing their virtualenvs to their repos, so NumPy source code is replicated a thousand times on the internets ;) including financial_test.py), and, well, I didn't go through all the ooooo's of Google but you get the picture. Making people used to IDL and MATLAB use namespaces is an issue completely unrelated to this in my opinion, or better put, much more general, because it affects the whole scientific Python ecosystem. Josef mentioned matplotlib.finance: https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/finance.... "This module is deprecated in 1.4 and will be moved to `mpl_toolkits`or it's own project in the future.". They might be in a similar situation than NumPy. I don't have an opinion on the usefulness of financial functions on NumPy and I have zero knowledge on finance myself, but if this discussion makes someone write a nice tutorial on using them (being on a subpackage or not) and attract people to actually use them (I would bet very few are doing so as of now), then great! My proposal is moving them to a separate subpackage as a first step to their disappearance. Maybe when someone sees the move and/or the deprecation note on the release notes that tutorial will be written :) Juan Luis Cano
participants (2)
-
Joe Harrington -
Juan Luis Cano