ENH: Session type, parse_session, new ExchangeCalendar methods #29
Conversation
| """ | ||
| try: | ||
| ts = pd.Timestamp(session) | ||
| except Exception: |
There was a problem hiding this comment.
Is the a more specific exception you can catch here?
There was a problem hiding this comment.
The try / except statement here is to identify when a user has passed a session as an object that is not a valid single-argument input to Timestamp. There are at least three errors that Timestamp can raise in this case (ValueError, TypeError and OutOfBoundsDatetime). Given the try clause contains only the command to create a Timestamp I felt it reasonable to leave the captured Exception bare in order to cover all circumstances(?).
Separately, I've revised the except clause to include the original error within the traceback so the user has visibility as to why the input failed.
| @@ -71,3 +82,96 @@ def compute_all_minutes( | |||
| ) | |||
| out = np.concatenate(pieces).view("datetime64[ns]") | |||
| return out | |||
|
|
|||
|
|
|||
| def parse_session( | |||
There was a problem hiding this comment.
Is the a reason not to put this as a function on the ExchangeCalendar class? Seems like you're only using it there and always passing self.
There was a problem hiding this comment.
I envisaged using it to parse start and end parameters received to ExchangeCalendarDispatcher.get_calendar (#31). To this end I've made revisions to allow calendar to take None if strict is False.
|
@maread99 Sorry for the delay here. Overall - looks good to me, but two small questions. |
|
The two conflicts seem to be the result of formatting in the merged #19. In each case the first version is as required. |
|
Ack - I seem to have just messed up the conflict fix rebase here - apologies. Would it be easier to close this, rebase #32 and I'll just approve + merge that (since IIRC it has all the same commits as this)? Sorry for the trouble. |
|
No worries, the merge was always going to fail on a test that I introduced Separately I've popped my 'Update XSES holidays' commit onto the end here and closed #32. I believe the commits under this PR are now clean and that it should all merge without an issue. References for the XSES holidays update: |
Introduces:
Sessiontype for parameters requiring a session label.parse_sessionfunction for verifying input.NotSessionErrorraised byparse_sessionwhensessionparses to UTC midnight but does not represent a session (only raised ifparse_sessionstrictparameter is True).Only implemented on public methods that would have otherwise raised an error for the given input. Note: Error type raised may differ from error type previously raised.
To avoid breaking changes, not implemented on public methods that return regardless of receiving a session_label as input that does not represent a session, for example,
sessions_in_range('2021-06-07', '2021-06-16 23:55'). Note: such input is ambiguous - in this example, if the 2021-06-17 session opened 2021-06-16 23:00 then should it be included?On any breaking release might be worth losing this ambiguity by verifying session inputs to ensure no time component, although allowing non-sessions so that the likes of sessions_in_range('2021-01-01', '2021-12-31') is valid. This can be handled by the
strictparameter ofparse_session(calendar, session, param_name, strict=False).PR also:
moves 'ExchangeCalendar._trading_minutes_nanos' to 'ExchangeCalendar.all_minutes_nanos' property. Exposes nanos and allows for benefit of lazyval decoration of 'ExchangeCalendar.all_minutes' (was being called by the constructor to evaluate
ExchangeCalendar._trading_minutes_nanos)type annotations to some
ExchangeCalendarmethods (for documentation purposes)new
ExchangeCalendarmethods:has_breaks-> bool. Does any session of calendar have a break.session_has_break-> bool. Does a given session have a break.