61–70 of 70 posts
I am amazed that `...` is a valid syntax in Python, not a pseudo grammar. This library is impressive, I appreciate it and I will apply it to my project.
What's the difference between '...' and the more common 'pass'?
Earlier quoted context omitted.
I found this was the most compact way to represent what I wanted to define, and makes it easy to keep the type hints for parameters. If you look inside `@prompt` it's creating a `PromptFunction` instance which I think would be a similar API to what you would end up with without using decorators https://github.com/jackmpcollins/magentic/blob/afdb22513385b...
I never got on board of decorators in python, but you sold me on it.
I am amazed that `...` is a valid syntax in Python, not a pseudo grammar. This library is impressive, I appreciate it and I will apply it to my project.
What's the difference between '...' and the more common 'pass'?
I am amazed that `...` is a valid syntax in Python, not a pseudo grammar. This library is impressive, I appreciate it and I will apply it to my project.
What's the difference between '...' and the more common 'pass'?
E.g, if I gave them this:
def foo(x):
... #add your implementation here
def bar(x):
pass #add your implementation here
def foo(x):
return x+1
def bar(x):
return x+1
passWrite some tests for those functions. It will be worth it. No, I am not kidding, especially for AI we need tests, but we should report accuracy instead of a hard fail/pass.
@prompt("Find out if {programs} are correct.")
def do_they_work(programs: list) -> bool:
...
Earlier quoted context omitted.
It is just a noop, but here it looks very appropriate/readable because it reads as saying "AI will fill this in".
It's a misuse of the Python Ellipsis, though PEP has no opinion on it. The Ellipsis is "Special value used mostly in conjunction with extended slicing syntax for user-defined container data types." In other words, it happens to work and look neat, but pass is the correct way to do it.
With that said, you are free to put any code in the function body including `pass` or just a docstring or even `raise NotImplementedError` - it will not be executed. Using Ellipses satisfies VSCode/pyright type checking and seemed neatest to me for the examples and docs. I have some additional notes on this in the README[2].
[0] https://stackoverflow.com/q/772124/9995080
[1] https://docs.python.org/3/library/typing.html#typing.overloa...
This looks really useful. Langchain is not my idea of a fun time. Love the examples too. Low-effort humor is the best: > create_superhero("Garden Man") > # Superhero(name='Garden Man', age=30, power='Control over plants', enemies=['Pollution Man', 'Concrete Woman'])
FWIW, at my last company we had a section in the developer guide encouraging using humor in tests - not only did it make them more fun to write, but it engaged the readership better.
We need a new language/DSL. Python is a lost cause for strings as first-class.
How so? What disadvantages does having strings as a first class Type have?
I meant we need a new DSL better suited for prompt engg, and a UI that better supports longer strings. Actualy this UI can be something compatible with Python.
But overall a reimagination of the dev experience is what I am getting at (like Jupyter for LLMs).
Dm me [redacted] on X for more.
Does this do System vs. Assistant vs. User prompting?
Right now we just pass a single user prompt to the chat model. Setting the system prompt could also be done in the `@prompt` decorator. I've added a github issue to track https://github.com/jackmpcollins/magentic/issues/31