Skip to content

consider adding helper functions or wrapper interface to simplify UX w/rt response types #290

@cprice404

Description

@cprice404

The 1.0 release uses our typical pattern for defining response types and making sure it is straightforward to see how to write correct, production-quality code, including error handling etc.

This UX feels a bit more complex in python than in most of the other languages we've built in. So while 1.0 will serve as a solid foundation for interacting with the service, python will most likely be the first language we will want to revisit to add some helper functions or wrapper interface for simplifying the most common use cases. e.g., we may want to provide hit_or_else accessors that handle some of the pattern matching, and/or we may want to provide a higher-level interface that returns the (nullable) hit value objects directly rather than exposing the response classes. Users could then opt into this less verbose interface if they preferred.

This ticket is to capture notes and ideas about what we might want to do here, as well as track any feedback we get from users who might be requesting something like this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions