feat(tasks): accept args in BaseTask.run()

[collindutter]

• I have read and agree to the contributing guidelines.

Describe your changes

BaseTask.run() now accepts args just like Structure.run(). Decided against adding kwargs support in this PR since there is a future opportunity for special kwargs like context=. Having a blackhole kwargs that is dumped into context makes it challenging to add kwargs that shouldn't go in context.

Issue ticket number and link

Closes #1597

---

📚 Documentation preview 📚: https://griptape--1598.org.readthedocs.build//1598/

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[vachillo]

@collindutter what else needs to be done here?

[collindutter]

I had some last minute ideas I wanted to try out. Will implement soon to see how they feel.

[collindutter]

@vachillo I updated/simplified the PR if you'd like to take one more look.

[vachillo]

@vachillo I updated/simplified the PR if you'd like to take one more look.

no kwargs now? any reason for that? description was updated

[collindutter]

@vachillo how does updated version look?

[vachillo]

i find it kind of confusing that there is two entrypoints into the prompt via args and context. what would be the advantage of either way?

[vachillo]

lets remove **kwargs here

[vachillo]

how does the move to .run for this line going to affect behavior?

[collindutter]

Reverted it

[vachillo]

should these be serializable?

[collindutter]

I don't think so, they are not intended to be static, serializable data.

[collindutter]

i find it kind of confusing that there is two entrypoints into the prompt via args and context. what would be the advantage of either way?

BaseTask.input is for defining the input to the LLM. In the case of PromptTask.input, it's a place for defining a text template.
BaseTask.context is for static data that needs to be made available that template.
BaseTask.run() args is for runtime data that needs to be made available to that template.

For example:

task = PromptTask(
    input="You are talking to {{ user_name }} ({{ user_id }}).They just said: {{ args[0] }}",
    context={
        "user_name": "John Doe",
        "user_id": "123",
    },
)


task.run("Hello, how are you?")
task.run("How do I foo the bar?")

[vachillo]

i find it kind of confusing that there is two entrypoints into the prompt via args and context. what would be the advantage of either way?

BaseTask.input is for defining the input to the LLM. In the case of PromptTask.input, it's a place for defining a text template. BaseTask.context is for static data that needs to be made available that template. BaseTask.run() args is for runtime data that needs to be made available to that template.

For example:

task = PromptTask(
    input="You are talking to {{ user_name }} ({{ user_id }}).They just said: {{ args[0] }}",
    context={
        "user_name": "John Doe",
        "user_id": "123",
    },
)


task.run("Hello, how are you?")
task.run("How do I foo the bar?")

i see. i think we just have very different ways of thinking about how this stuff gets run. to me, its unrealistic that you would invoke task.run twice like that. every instanstiation of objects is in completely seperate processes, and gets spun up with all the data that is needed dynamically. so i dont see context as any less "dyanmic" than args, just a different entrypoint. like an event driven case where you are spinning everything up every time. its just optimizing for very different scenarios.

[collindutter]

to me, its unrealistic that you would invoke task.run twice like that. every instanstiation of objects is in completely seperate processes

It would be preferable if you didn't need to create a new Task every time though, as there is some overhead associated with creating it. With the upcoming async work I think that model becomes more feasible since you can run the async work on the main thread vs creating a new one.