Live data from Hacker News

I scraped all of OpenAI's Community Forum

julep-ai.github.io

51–60 of 68 posts

Re: I scraped all of OpenAI's Community Forum

#51

> Number of Posts with negative sentiment, grouped by Topic > # 1 Result: Python Packaging Checks out

A pro-tip for using the OpenAI API is to not use the official Python package for interfacing with it. The REST API documentation is good, and just using it in your HTTP client of choice like requests is roughly the same LOC without unexpected issues, along with more control.

Hey minimaxir, I help maintain the official OpenAI Python package. Mind sharing what issues you've had with it? (Have you used it since November, when the 1.0 was released?)

Keen for your feedback, either here or email: alex@stainlessapi.com

Re: I scraped all of OpenAI's Community Forum

#52

Earlier quoted context omitted.

A pro-tip for using the OpenAI API is to not use the official Python package for interfacing with it. The REST API documentation is good, and just using it in your HTTP client of choice like requests is roughly the same LOC without unexpected issues, along with more control.

I've found this happens with a lot of first party clients. At work, we use LaunchDarkly for feature flags and use their code references tool to keep track of where flags are being referenced. The tool uses their first party Go client to interact with the API but the client doesn't handle rate limiting at all even though they have rate limiting headers clearly documented for their API.

First party clients are typically an afterthought, and you can't add features without getting a PM to sign off, which strangles the impulse to polish & sand down rough edges.

Re: I scraped all of OpenAI's Community Forum

#54

> Number of Posts with negative sentiment, grouped by Topic > # 1 Result: Python Packaging Checks out

FWIW, here are the only links I could find in the article which were tagged "Python3 Package": https://community.openai.com/t/647723 and https://community.openai.com/t/586484 . Note they don't see to have anything to do with the Python package whatsoever.

I was pretty disappointed to see this, as I work on the Python package and was hoping for a good place to find feedback (apart from the github issues, which I monitor pretty closely).

I'm not a data scientist; maybe someone from the Julep team could comment on the labeling? Or how I could find some more specific themes of problems with the Python package? (Was it just that people who have a problem of some kind just happen to also use the Python library?)

Re: I scraped all of OpenAI's Community Forum

#55
post #52

Earlier quoted context omitted.

I've found this happens with a lot of first party clients. At work, we use LaunchDarkly for feature flags and use their code references tool to keep track of where flags are being referenced. The tool uses their first party Go client to interact with the API but the client doesn't handle rate limiting at all even though they have rate limiting headers clearly documented for their API.

First party clients are typically an afterthought, and you can't add features without getting a PM to sign off, which strangles the impulse to polish & sand down rough edges.

Agreed. Any in particular come to mind that you'd like to see improved?

(my company provides first-party clients with a lot of polish; maybe we could help)

Re: I scraped all of OpenAI's Community Forum

#56
post #53

What's the "Day Knowledge Direction" cluster in the Atlas view?

Neat find! That's actually a cluster of all the system messages notifying users about closing and re-opening of the thread. That's why they're so tightly clustered.

I believe the naming isn't perfect for this, but this was all automatic topic modelling!

Example: [1]: https://community.openai.com/t/read-this-before-posting-a-ne...

Re: I scraped all of OpenAI's Community Forum

#58
post #54

> Number of Posts with negative sentiment, grouped by Topic > # 1 Result: Python Packaging Checks out

FWIW, here are the only links I could find in the article which were tagged "Python3 Package": https://community.openai.com/t/647723 and https://community.openai.com/t/586484 . Note they don't see to have anything to do with the Python package whatsoever. I was pretty disappointed to see this, as I work on the Python package and was hoping for a good place to find feedback (apart from the github issues, which I monit…

Hey! Happy to chat over email/X more closely and help you out.

Nomic Atlas automatically generates the labels here. There could be different variations of posts involving the Python Packages.

But I did some manual digging & here's what I found; Heading over to the map and filtering by posts around "Python Packages" leads to around 900 posts.

Sharing a few examples which do talk about people's posts related to the python package:

- https://community.openai.com/p/701058 - https://community.openai.com/p/652075 - https://community.openai.com/t/32442 - https://community.openai.com/p/143928

Note: My intuition is that most of the posts are very basic, probably user errors like "No API Key Found" etc.

Re: I scraped all of OpenAI's Community Forum

#59
post #51

Earlier quoted context omitted.

A pro-tip for using the OpenAI API is to not use the official Python package for interfacing with it. The REST API documentation is good, and just using it in your HTTP client of choice like requests is roughly the same LOC without unexpected issues, along with more control.

Hey minimaxir, I help maintain the official OpenAI Python package. Mind sharing what issues you've had with it? (Have you used it since November, when the 1.0 was released?) Keen for your feedback, either here or email: alex@stainlessapi.com

There's nothing wrong per se, it works as advertised. But as a result it's a somewhat redundant dependency.

Re: I scraped all of OpenAI's Community Forum

#60
post #51

Earlier quoted context omitted.

Hey minimaxir, I help maintain the official OpenAI Python package. Mind sharing what issues you've had with it? (Have you used it since November, when the 1.0 was released?) Keen for your feedback, either here or email: alex@stainlessapi.com

There's nothing wrong per se, it works as advertised. But as a result it's a somewhat redundant dependency.

Ah, gotcha. Thanks, that makes sense. FWIW, here are some things it provides which might be worth having:

1. typesafety (for those using pyright/mypy) and autocomplete/intellisense

2. auto-retry (w/ backoff, intelligently so w/ rate limits) and error handling

3. auto-pagination (can save a lot of code if you make list calls)

4. SSE parsing for streaming

5. (coming soon) richer streaming & function-calling helpers (can save / clean up a lot of code)

Not all of these matter to everybody (e.g., I imagine you're not moved by such benefits as "dot notation over dictionary access", which some devs might really like).

I would argue that auto-retry would benefit a pretty large percentage of users, though, especially since the 429 handling can paper over a lot of rate limits to the point that you never actually "feel" them. And spurious/temporary network connections or 500s also ~disappear.

For some simple use-cases, none of these would really matter, and I agree with you - especially if it's not production code and you don't use a type-aware editor.

Post reply on HN