rattray

We don't have a YoE cutoff, but we aren't hiring junior developers right now.

Something that I feel is missing – someone please let me know if I missed it – is how long this bug was materially present in packages? how many people likely were exposed to it?

Stainless | Generalist Engineers, First AE | NYC ONSITE | Full-time

Stainless is building the platform for high-quality, easy-to-use APIs. Our first product is SDKs as a service. When you `npm install openai` or `pip install openai`, for example, you’re downloading code that we generated. (I built the codegen system at Stripe for their SDKs, and am now building a better version for everyone.)

Next, we want to make it easy to build amazing REST APIs. REST is simple and ubiquitous, but right now it’s also messy, chaotic, and hard to get right. We’re going to build great open-source standards and tooling that bring the benefits of GraphQL (types, field selection/expansion, standards) and gRPC (types, speed, versioning) to REST.

We’re ~2y old, ~10 people, have strong revenue (could choose to be profitable), and great customers (including OpenAI, Anthropic, and Cloudflare). We’re backed by Sequoia.

As a founding engineer, you’ll get autonomy to build great products, skilled peers, opportunity for tremendous impact, competitive salary, and a very competitive ownership stake.

We’re looking for exceptionally productive, thoughtful, tasteful, and kind people with a passion for making software development better for everyone.

Want to build the future of API tooling? Say hi: alex at stainlessapi.com

gotcha, that makes sense - thank you!

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.

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)

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?)

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

Another good option for this kind of thing is Optic: https://www.useoptic.com/docs/generate-openapi-from-tests

Delighted to hear that!

Very happy Grit customer here. Wish I'd had this instead of jscodeshift et al back when I was doing oodles of migrations at Stripe, but glad I have it now, and very excited to see them go open-source!

Have you seen/tried the `.runTools()` helper?

Docs: https://github.com/openai/openai-node?tab=readme-ov-file#aut...

Example: https://github.com/openai/openai-node/blob/bb4bce30ff1bfb06d...

(if what you're fundamentally trying to do is really just get JSON out, then I can see how json_mode is still easier).

I'm sorry for your experience, and thanks very much for sharing the code snippet - that's helpful!

We did indeed code up some sample apps and highlighted this exact concern. We have some helpers planned to make it smoother, which we hope to launch before Assistants GA. For streaming beta, we were focused just on the streaming part of these helpers.

Hey there, I helped design the Python library.

The `stream` context manager actually does expose an async iterator (in the async client), so you could instead do this for the simple case:

    with client.beta.threads.runs.create_and_stream(…) as stream:
      async for text in stream.text_deltas:
        print(text, end="", flush=True)

which I think is roughly what you want.

Perhaps the docs should be updated to highlight this simple case earlier.

We are also considering expanding this design, and perhaps replacing the callbacks, like so:

    with client.beta.threads.runs.create_and_stream(…) as stream:
      async for event in stream.all_events:
        if event.type == 'text_delta':
          print(event.delta.value, end='')
        elif event.type == 'run_step_delta':
          event.snapshot.id
          event.delta.step_details...

which I think is also more in line with what you expect. (you could also `match event: case TextDelta: …`).

Note that the context manager is required because otherwise there's no way to tell if you `break` out of the loop (or otherwise stop listening to the stream) which means we can't close the request (and you both keep burning tokens and leak resources in your app).

Thank you. I added this myself, but with option instead of shift (because cmd+shift+v already does "paste without formatting" iirc) like so:

    -- https://news.ycombinator.com/item?id=39640745
    hs.hotkey.bind({"cmd", "alt"}, "V", function()
      hs.eventtap.keyStrokes(hs.pasteboard.getContents())
    end)

For context, the reason I ask is that I am developing some Ruby gems, and considering whether it's worth adding .rbs files.

In the Python libraries I maintain, types are useful to anyone who installs the default Python VS Code plugin, because it gives them intellisense (but doesn't give them red squiggly lines for type errors) even if they do nothing to set up types or a typechecker.

Is that or will that be the case for Ruby/Steep?

Nice! Does the Steep LSP for VS Code give you nice intellisense even if you don't have rbs files? How's the speed?

No mention of Sorbet. Is anyone (outside of Stripe, Shopify, etc) using it?

Agreed - is the problem really that heavy dilution occurred, or that the startup became ~worthless? (as most do)

It is worth bearing in mind when folks are joining an early stage company (as cofounder or founding engineer) that dilution will occur, and that - especially if you don't stay with the company and continue to be valuable - it may be heavy (though usually not nearly this heavy)

Stainless | Founding Engineer | NYC ONSITE | Full-time

Stainless is building the platform for high-quality, easy-to-use APIs. Our first product is SDKs as a service. When you `npm install openai` or `pip install openai`, for example, you’re downloading code that we generated. (I built the codegen system at Stripe for their SDKs, and am now building a better version for everyone.)

Next, we want to make it easy to build amazing REST APIs. REST is simple and ubiquitous, but right now it’s also messy, chaotic, and hard to get right. We’re going to build great open-source standards and tooling that bring the benefits of GraphQL (types, field selection/expansion, standards) and gRPC (types, speed, versioning) to REST.

We’re about 2y old, under 10 people, have strong revenue, and are selling to companies you interact with every day (OpenAI, Anthropic, and Cloudflare are all customers). We’re backed by Sequoia.

As a founding engineer, you’ll get autonomy to build great products, skilled peers, opportunity for tremendous impact, competitive salary, and a very competitive ownership stake.

We’re looking for exceptionally productive, thoughtful, tasteful, and kind people with a passion for making software development better for everyone.

Want to build the future of API tooling? Say hi: alex at stainlessapi.com

Nice, congrats!

This must have been a huge lift – when we launched support for browsers/bun/deno/node/etc along with CJS & ESM from the same npm package, it was a surprising amount of work.

(disclaimer, we offer a similar service: https://stainlessapi.com)

That definitely doesn't look like something that could handle a human walking, and seems to be using a very different technique.

It's opt-in:

> Developers can choose to adopt these new business terms, or stay on Apple’s existing terms. Developers must adopt the new business terms for EU apps to use the new capabilities for alternative distribution or alternative payment processing.

So you either choose US/Global Business Model (what we know today), or EU Business Model (what was announced today, with flexibility but high fees). You can distribute on the App Store either way.

Would you be willing to share your prompts? I bet a lot of people would find them useful!

How does it compare to Superhuman? (I use that now)

What are some good stats/benchmarks on the rough order of magnitude of python vs js perf these days?

Stainless | Founding Engineer and Contract Designer | NYC ONSITE | Full-time or Contract

Stainless is building the platform for high-quality, easy-to-use APIs.

Our first product is SDKs as a service. When you `npm install openai` or `pip install openai`, for example, you’re downloading code that we generated.

(I built the codegen system at Stripe for their SDKs, and am now building a better version for everyone.)

Next, we want to make it easy to build amazing REST APIs. REST is simple and ubiquitous, but right now it’s also messy, chaotic, and hard to get right. We’re going to build great open-source standards and tooling that bring the benefits of GraphQL (types, field selection/expansion, standards) and gRPC (types, speed, versioning) to REST.

We’re about 2y old, under 10 people, have strong revenue, and are selling to companies you interact with every day (OpenAI, Anthropic, and Cloudflare are all customers). We’re backed by Sequoia.

As a founding engineer, you’ll get autonomy to build great products, skilled peers, opportunity for tremendous impact, competitive salary, and a very competitive ownership stake.

As a designer, you’ll be building the future of API documentation alongside the lead engineer on Stripe’s current API docs design, and some rich, interesting devtool products.

We’re looking for exceptionally productive, thoughtful, tasteful, and kind people with a passion for making software development better for everyone.

Want to build the future of API tooling? Say hi: alex at stainlessapi.com

OOC, what was painful about maintaining Sorbet compared to, say, TypeScript?

Is there a llamafile?

For both social and work life it's an important way of communicating for many people.

Some people are just a little less quick to message you back if you're a green bubble or ask to use WhatsApp, especially in certain circles.