Python async - #142
Python async#142melindafekete wants to merge 7 commits into
Conversation
|
🌿 Preview your docs: https://unleash-preview-python-async.docs.buildwithfern.com Here are the markdown pages you've updated: |
There was a problem hiding this comment.
Pull request overview
Expands the Python SDK documentation with async-client guidance and broader SDK reference content.
Changes:
- Adds sync and async initialization examples.
- Documents configuration, events, metrics, caching, testing, and troubleshooting.
- Refreshes terminology and code examples.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
ppicom
left a comment
ppicom
left a comment
There was a problem hiding this comment.
hey melinda! Awesome work, I've left a few comments that came to mind while reading the draft.
Maybe it's a good idea to wait before merging this one, though. We're not entirely done with the async client and there could be some changes on how the internals work.
| - `appName` and `environment` are set from the client configuration. | ||
| - `currentTime` is set to the current UTC time when you don't provide it, so date-based constraints work without extra setup. | ||
| - Any top-level key that isn't a standard context field is moved into `properties`. Passing `{"custom-property": "some-value"}` at the top level is equivalent to nesting it under `properties`. |
There was a problem hiding this comment.
question: aren't this internals of the SDK? Do users use this information?
There was a problem hiding this comment.
hmm I feel like it sits in the category of observable behavior that users depend on. it explains why date constraints work without passing currentTime, and why a top-level custom property behaves the same as one nested under properties. I think it's better to document then have them discover it by trial and error? but happy to remove if we think that's better
Small cheeky restructure + introduce async client