use trading_calendars in zipline #2219
Conversation
vikram-narayan
force-pushed
the
use-trading-calendars
branch
2 times, most recently
from
506b9cf
to
16dc5d7
Compare
vikram-narayan
changed the title
|
@ssanderson mind taking a look? |
There was a problem hiding this comment.
@vikram-narayan the changes here generally seem reasonable. A few general comments:
- It looks like some of the functions we copied to zipline have been deleted here but others haven't (e.g., it looks like we copied
preprocessbut movedlazyval,coerce, anddays_at_time. It seems like we should be consistent one way or another here. - I'm not sure if we want to have a single global registry for all consumers of
trading_calendars, or if we want a zipline-specific registry (multipledispatch, which we use in various places, has a concept of a dispatch namespace, which you can use to have multiple distinct copies of multiply-dispatched functions with the same name. The analogy here would be if you wanted multiple different calendars registered under the same name in different parts of your program. I can't actually think of a use-case where that would be useful, so my inclination for now is to have the single global registry, but I'd be interested to get other opinions on this. - I'm 50/50 on whether it's worth the source code churn to update all the imports here. This is another case where I'd be interested in a second opinion.
| @@ -0,0 +1,11 @@ | |||
| # flake8: noqa | |||
There was a problem hiding this comment.
One thing I'm not sure of is whether we want to re-export the global registry from trading_calendars or if we want Zipline to maintain its own distinct registry.
There was a problem hiding this comment.
Like you I don't know of a use case off the top of my head where we'd need this; presumably if the calendars are different, we'd want to register them differently. Do you think it's still worth adding the multipledispatch logic in case we need it later?
There was a problem hiding this comment.
I think we can probably punt on this until we have a use-case for it.
zipline/utils/input_validation.py
Outdated
| @@ -21,6 +21,7 @@ | |||
| from six import iteritems, string_types, PY3 | |||
| from toolz import valmap, complement, compose | |||
| import toolz.curried.operator as op | |||
| from trading_calendars.trading_calendar import coerce | |||
There was a problem hiding this comment.
How are we using coerce in trading_calendar if preprocess is still defined in zipline?
There was a problem hiding this comment.
Assuming we're still using it, trading_calendars.trading_calendar seems like an odd place for this to live. My inclination would honestly be to put the stuff we ported from zipline in something that makes that clear like trading_calendars._from_zipline or something like that.
There was a problem hiding this comment.
yup definitely makes sense to move these to a better location. if we're planning to keep these functions here permanently, should these be in trading_calendars.utils or something? might be a bit confusing to see _from_zipline in a repo that isn't zipline, that is used by zipline
There was a problem hiding this comment.
opened a PR in trading_calendars putting these functions in utils: quantopian/trading_calendars#4, lmk what you think about those locations
There was a problem hiding this comment.
Those seem fine. I think at some point we'll want to push preprocess into its own library, but we can save that for another day.
tests/data/bundles/test_core.py
Outdated
| @@ -36,7 +36,7 @@ | |||
| ) | |||
| from zipline.utils.cache import dataframe_cache | |||
| from zipline.utils.functional import apply | |||
| from zipline.utils.calendars import TradingCalendar, get_calendar | |||
| from trading_calendars import TradingCalendar, get_calendar | |||
There was a problem hiding this comment.
I'm 50/50 on whether it's worth changing all these imports to point to the new repo, or if we should just leave all of this the same (which should still work since we're re-exporting). Might be worth asking around internally to see if people have preferences about this.
There was a problem hiding this comment.
I think we should import from the real place, but move the import to be in the 3rd partly lib section. The re-export should continue to work for a while or we will break a lot of code in our data processing projects.
There was a problem hiding this comment.
asked around and people prefer importing from trading_calendars; moved imports to 3rd party section
| @@ -111,10 +111,6 @@ def window_specialization(typename): | |||
| 'zipline.data._minute_bar_internal', | |||
| ['zipline/data/_minute_bar_internal.pyx'] | |||
| ), | |||
| Extension( | |||
|
LGTM once the buidl passes. |
- remove zipline.utils.calendars - update imports - add trading-calendars to requirements
vikram-narayan
force-pushed
the
use-trading-calendars
branch
from
47e3fc1
to
45fb9ba
Compare
Replace zipline.utils.calendars with trading_calendars.