Lift some API to the top level

[hayd]

Some functions should be added to the top level __init__, and some modules.

It's annoying that import pandas_datareaders doesn't allow you to tab in to explore the module, and more importantly tab-explore the "useful functions".

This may require some careful directory restructuring (in a backwards compatible way).

DataReader should obviously be toplevel, I'm not sure about the wb stuff (as the function names don't mention wb)... some bikeshedding is required here.

[femtotrader]

+1

[femtotrader]

The case of wb.py is interesting as I think it's now the only one data reader which is not using requests session.

One problem (in my mind) is that DataReader (or an other function, let's call it DataReaderObject) should return an object... not directly "data"

So we could have

DataReaderObject("wb").search(string='gdp.*capi', field='name', case=False)

DataReaderObject("wb").get_indicators()

Same could apply to Options

DataReaderObject("YahooOptions").get('aapl').get_all_data()

or

DataReaderObject("YahooOptions")['aapl'].get_all_data()

This DataReaderObject could be at top level and could become the prefered way to use pandas-datareader (only ONE entry point)

What is odd with current design is that DataReader first parameter is name (symbol), not data_source but we still need to support this (to be backwards compatible) !

What is your opinion @sinhrks ? @davidastephens ?

[davidastephens]

Why one entry point like that? We could maintain for backwards compatibility our get_data_yahoo functions and also add your object entry points.

Another idea I was thinking of was having a 'Equity' object. We would have default datareaders to provide each piece of data, but they could be modified.

AAPL = Equity('AAPL')
AAPL.dividend
AAPL.splits
AAPL.options.get_all_data()

With that kind of set up, you could start adding some other useful methods to the object (unclear whether it would be in this package or another one). Things like charting, option valuation, fundamental analysis, technical analysis, etc.

[femtotrader]

In such a case we should also be able to do

equities = Equity(['AAPL', 'MSFT'])
equities.dividend
equities.splits
equities.options.get_all_data()

[sinhrks]

I prefer separate class for reader-related and option-related classes.

For the reader-related classes, how about:

• Deprecate data.DataReader
• Add Reader class to top-level which returns corresponding Reader by name.
• Once-created Rader can be used by changing the options.

r = Reader('yahoo', 'AAPL', start='2011-01-01', session=session)
r.read()

# reader can be created without symbol, and overwrite via read
r = Reader('yahoo', start='2011-01-01')
r.read('AAPL', start='2014-01-01')
# read data should start from 2014-

[davidastephens]

I think finance related logic (ie: that options go with equities) should be in a different package and use pandas-datareader as the api for getting data. I've started a package here:
https://github.com/davidastephens/pandas-finance

[sinhrks]

Can't this be a subpackage of data-reader? I think it splits to too small units.

[davidastephens]

I think it will end up getting fairly large and have a significant amount of non-datareading code (at least as I am planning it). Can merge parts of it into pandas-datareader if its complementary.

[hayd]

I was thinking get_data_google, get_data_yahoo, etc. Personally I prefer using explicitly named methods rather than passing strings (via DataReader).

[femtotrader]

I really think that first parameter of function at packackage level should be reader name not symbol.
I also think that

r = Reader('yahoo', 'AAPL', start='2011-01-01', session=session)
r.read()

is not a great idea. I would prefer

r = Reader('yahoo', session=session)
r.read('AAPL', start='2011-01-01')

because a reader could have other method than read (see fir example wb.py)

I personally don't like method like get_data_google, get_data_yahoo ...
(I thought we decided to deprecated them.

A pandas_finance package which provide a higher level API and use pandas-datareader is a good idea but does this package goal is just about reading financial data ? in such a case pandas-datareader-finance name is probably better but if a significant amount of non-datareading code pandas-finance name is great.

[davidastephens]

I also like the get_data_google, etc functions. Mostly because I can tab complete them.

[femtotrader]

So if everyone like that (this is not my case) we might remove

# ToDo: deprecate

in data.py