OpenBB Script Routines major improvement #5005

DidierRLopes · 2023-05-11T10:36:11Z

See current state here: https://twitter.com/didier_lopes/status/1656788265293459457?s=20

New features:

Allows to create variables
Allows to do for loops
Allows to slice ARGV or other vars
Documentation added
Decisions regarding some framework decisions I took- $ for args, $$ for var iterating in loops, 0-index, slicing like python
Several tests added here on tests/openbb_terminal/routines/test_routines.py - to be run with pytest tests/openbb_terminal/routines/test_routines.py

It doesn't has the capability of taking output from a command, thus the if/else is not a priority as the user controls the inputs. Taking output from command will likely require a big rewrite since that's not something our current infra supports.

DidierRLopes · 2023-05-11T10:39:19Z

CC: @the-praxs

ronstone2000 · 2023-05-11T10:59:16Z

I like this. Your example hints at an extension that would make it even more flexible. Simple date manipulation:

END=today # A keyword that grabs the system date
START=$END-30 # (Some syntax that offsets a date)
DATES=$START,$END
...

DidierRLopes · 2023-05-11T11:14:12Z

I like this. Your example hints at an extension that would make it even more flexible. Simple date manipulation:

END=today # A keyword that grabs the system date START=$END-30 # (Some syntax that offsets a date) DATES=$START,$END ...

That's a great idea.

we can have some reserved keywords like LASTYEAR, LASTMONTH, LASTWEEK for dates. I'm wondering if there's any other type of keywords that we could use.

The offset is interesting but is hard to know what are we offsetting. Days? Months? Years?

ronstone2000 · 2023-05-11T11:33:56Z

I was thinking days. I would not know exactly what LASTMONTH etc mean. Beginning of last month, end, April 11? Prebaked keywords would be helpful, but I may find them limiting if I want to work with arbitrary offsets from arbitrary dates. Say I'm an academic doing historical research and the baseline from which I want to look at stats is 10-10-2008, going back 3yrs ...

END=10-10-2008
BEGIN=$END-1095 # 10-10-2005

the-praxs · 2023-05-11T15:28:05Z

Rather than ARGV we can assign input argument values to a keyword called INPUT. This will prevent the user from overriding ARGV. Extending this, it means whatever arguments other than input is used can be used as a keyword for the script.

I am thinking about 0 vs 1-based indexing. If our user base is less technical, they will find it easier to use 1-based indexing. Programmers are comfortable with 0 already.

One cool feature I thought about is to provide the location of the output window for charts/tables i.e. top, center, bottom, or simply a row-column index like (1,2) (depending on the type of indexing) or to simplify more, 1,2,3 where everything goes top to bottom, left to right.

the-praxs · 2023-05-11T15:36:39Z

For

I like this. Your example hints at an extension that would make it even more flexible. Simple date manipulation:
END=today # A keyword that grabs the system date START=$END-30 # (Some syntax that offsets a date) DATES=$START,$END ...

That's a great idea.

we can have some reserved keywords like LASTYEAR, LASTMONTH, LASTWEEK for dates. I'm wondering if there's any other type of keywords that we could use.

The offset is interesting but is hard to know what are we offsetting. Days? Months? Years?

CURRENT_DATE, QUARTER_1/Q1, QUARTER_2/Q2, Q2.DATE, Q2.MONTH etc?

deeleeramone · 2023-05-11T21:12:57Z

I like this. Your example hints at an extension that would make it even more flexible. Simple date manipulation:
END=today # A keyword that grabs the system date START=$END-30 # (Some syntax that offsets a date) DATES=$START,$END ...

That's a great idea.

we can have some reserved keywords like LASTYEAR, LASTMONTH, LASTWEEK for dates. I'm wondering if there's any other type of keywords that we could use.

The offset is interesting but is hard to know what are we offsetting. Days? Months? Years?

As a usage example, I would like to have a routine that can query the economic and earnings calendars for the current or upcoming week without the need to explicitly state values for [start_date,end_date]. Keywords might be something like NEXTMONDAY, NEXTFRIDAY, LASTFRIDAY, THISMONDAY.

DidierRLopes · 2023-05-11T22:32:34Z

I was thinking days. I would not know exactly what LASTMONTH etc mean. Beginning of last month, end, April 11? Prebaked keywords would be helpful, but I may find them limiting if I want to work with arbitrary offsets from arbitrary dates. Say I'm an academic doing historical research and the baseline from which I want to look at stats is 10-10-2008, going back 3yrs ...

END=10-10-2008 BEGIN=$END-1095 # 10-10-2005

I think I'd rather for us to create our own convention, e,g. having valid 1YEARAGO, 2YEARSAGO, 3YEARSAGO, ... being valid

DidierRLopes · 2023-05-11T22:35:53Z

Rather than ARGV we can assign input argument values to a keyword called INPUT. This will prevent the user from overriding ARGV. Extending this, it means whatever arguments other than input is used can be used as a keyword for the script.

I am thinking about 0 vs 1-based indexing. If our user base is less technical, they will find it easier to use 1-based indexing. Programmers are comfortable with 0 already.

One cool feature I thought about is to provide the location of the output window for charts/tables i.e. top, center, bottom, or simply a row-column index like (1,2) (depending on the type of indexing) or to simplify more, 1,2,3 where everything goes top to bottom, left to right.

I like ARGV because it's Perl convention, but I understand that INPUT is more straightforward probably for 90% of users.

The programmer in my wants do die with 1-based indexing, but for less technical users it may be the right thing to do.

The screen position could potentially work. @tehcoderer would it be possible to have optional args for all commands that select where output lands on? Not sure if ROI for that one is worth, but would be good to know if at least possible!

QUARTER1, QUARTER2 convention sounds good.

Will work on a few improvements over weekend

DidierRLopes · 2023-05-11T22:36:25Z

I like this. Your example hints at an extension that would make it even more flexible. Simple date manipulation:
END=today # A keyword that grabs the system date START=$END-30 # (Some syntax that offsets a date) DATES=$START,$END ...

That's a great idea.
we can have some reserved keywords like LASTYEAR, LASTMONTH, LASTWEEK for dates. I'm wondering if there's any other type of keywords that we could use.
The offset is interesting but is hard to know what are we offsetting. Days? Months? Years?

As a usage example, I would like to have a routine that can query the economic and earnings calendars for the current or upcoming week without the need to explicitly state values for [start_date,end_date]. Keywords might be something like NEXTMONDAY, NEXTFRIDAY, LASTFRIDAY, THISMONDAY.

Good idea. I'll create a dictionary for us for these 🙏🏽

deeleeramone · 2023-05-12T04:29:31Z

Good idea. I'll create a dictionary for us for these 🙏🏽

Maybe a smarter way to accomplish all of these, but if it gets the ball rolling, no harm in sharing. :)

def date_today() -> datetime:
    return (datetime.today())

def date_today_shift(ndays:int = 0) -> datetime:
    return (datetime.today() + timedelta(days=ndays))

def last_monday() -> datetime:
    if datetime.today().weekday() != 0:
        return (datetime.today() + timedelta(datetime.weekday(datetime.today())*(-1)))
    else:
        return (datetime.today() + timedelta(days = -7))

def next_monday() -> datetime:
    if datetime.today().weekday() == 0:
        return (datetime.today() + timedelta(days = 7))
    else:
        return (last_monday()+timedelta(days = 7))

the-praxs · 2023-05-12T07:09:02Z

Rather than ARGV we can assign input argument values to a keyword called INPUT. This will prevent the user from overriding ARGV. Extending this, it means whatever arguments other than input is used can be used as a keyword for the script.
I am thinking about 0 vs 1-based indexing. If our user base is less technical, they will find it easier to use 1-based indexing. Programmers are comfortable with 0 already.
One cool feature I thought about is to provide the location of the output window for charts/tables i.e. top, center, bottom, or simply a row-column index like (1,2) (depending on the type of indexing) or to simplify more, 1,2,3 where everything goes top to bottom, left to right.

I like ARGV because it's Perl convention, but I understand that INPUT is more straightforward probably for 90% of users.

The programmer in my wants do die with 1-based indexing, but for less technical users it may be the right thing to do.

The screen position could potentially work. @tehcoderer would it be possible to have optional args for all commands that select where output lands on? Not sure if ROI for that one is worth, but would be good to know if at least possible!

QUARTER1, QUARTER2 convention sounds good.

Will work on a few improvements over weekend

Perfect! I will review the code in the mean time and think about some features/keywords.

ronstone2000 · 2023-05-12T18:19:47Z

I think I'd rather for us to create our own convention, e,g. having valid 1YEARAGO, 2YEARSAGO, 3YEARSAGO, ... being valid

Works for me. I'd like to see 1WEEKAGO, 2WEEKSAGO, 1MONTHAGO etc intervals (I,e, near past offsets)

DidierRLopes · 2023-05-14T08:48:42Z

This should do.

Screen.Recording.2023-05-14.at.1.46.35.AM.mov