Typing about dspy

[okhat]

Hey, this sounds excellent and I want to dig deeper. Not sure if you follow my Twitter updates on this, but we have built a v2 (called DSPy) that we're releasing like ... in 2-3 days. It's not a rewrite actually, it's a much cleaner and more powerful wrapper around DSPv1, but I can't tell if it will resolve some of your concerns or not.

So I'd like to understand your concerns.

dynamic behavior that could lead to hard to debug errors when something will change between versions

Versions of? The framework itself? Or a program built in it? Basically, I might need an example of this to understand what you mean.

What is the advantage of Pydantic here? What kind of validation are you thinking of?

[okhat]

One issue we did fix in DSPy (i.e., v2) is that the generate functions will take kwargs and not "x" (dsp.Example). This is a lot less opaque and causes fewer issues.

This sounds like it interacts with your concerns on validating which fields are where.

[lambdaofgod]

By validation I meant that for example when I removed 'demos' argument in vanilla_LM_QA from "demonstrate_search_predict" notebook I got an error in generate function and not in Example itself. Pydantic wouldn't let me create an object if I didn't pass the required field or if it had incorrect type (it would fail instantly thus making debugging far easier).

I'm looking forward for v2, when it drops I'll try to write these classes for validation.