Fix for function-calling python example; unpack arguments first!

Documentation
1

Running the function-calling python example verbatim gives an unexpected result, I found a fix just adding ** - I think this is what was intended by the author.

The example here gives a get_horoscope function, and the prompt instructions are to “Respond only with a horoscope generated by a tool.” with the example user prompt saying “I’m an Aquarius” so the expected result is to be printed is just the output of get_horoscope with “Aquarius” being passed in as the sign, but the example accidentally passes a dictionary with the arguments by name to the function, and that whole dictionary ends up being the “sign”, output is:

{‘sign’: ‘Aquarius’}: Next Tuesday you will befriend a baby otter.

Fix is to call get_horoscope(**json.loads(item.arguments)) instead! Fix is only on line 47 but you should check the javascript for the same issue:

    `horoscope = get_horoscope(**json.loads(item.arguments))`
2 Likes
2

More of an issue besides the naive output parsing of a response (and the “function” accepting “whatever” as its printout without any type hinting: The “chat completions” mode simply doesn’t work, and doesn’t provide the correct documentation for function-calling, still showing a responses.create API method even after the page URL is refreshed:

Untitled
Untitled1173×268 43.1 KB

Use of “responses” API is especially unjustifiable for excusively developer functions, as this endpoint is where you get repeated loops of non-stop structured output failure for no good reason, while chat completions remains relatively stable. Therefore, Chat Completions documentation must work, and better, be more notebook-like, showing the intermediary state of variables to know whether “json.loads()” is warranted and possible on an SDK response object packed up with Pydantic with “arguments” within.