Python’s flexibility is one of its greatest strengths — but it can also be a source of subtle inconsistencies. A function might return a raw value, a tuple,Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Dev2Forge/BasicReturns/llms.txt
Use this file to discover all available pages before exploring further.
None, raise an exception, or return a boolean flag depending on its author and mood. Over time these ad-hoc patterns pile up: callers never know whether to check for None, catch an exception, or unpack a tuple. BasicReturns solves this at the root by giving every function a single, predictable return contract built on two Pydantic v2 models — BasicReturn and DataAndMsgReturn — so every response across your codebase shares the same shape, the same field names, and the same failure protocol.
The Two Classes
BasicReturns exports exactly two models. Both are PydanticBaseModel subclasses, which means they carry full type annotations, runtime validation, and a built-in to_dict() serialization method.
BasicReturn
The minimal return contract. Carries an
ok flag and an error field.
Ideal for write operations, void-style procedures, or any operation where
the caller only needs to know whether it succeeded.DataAndMsgReturn
Extends
BasicReturn with a human-readable msg string and a data
payload. Use this whenever the caller needs to consume a result — fetched
records, computed values, parsed files, API responses, and so on.BasicReturn
| Field | Type | Default | Purpose |
|---|---|---|---|
ok | Optional[bool] | True | True on success, False on failure — mirrors HTTP 2xx/4xx. |
error | Optional[Any] | None | Holds the exception or error detail when ok is False. |
DataAndMsgReturn
ok and error from BasicReturn and adds:
| Field | Type | Default | Purpose |
|---|---|---|---|
msg | Optional[str] | None | A human-readable message describing what happened. |
data | Optional[Any] | None | The return payload — any Python object, list, dict, model, etc. |
When to Use Each Class
UseBasicReturn when your function performs a side effect (writing a file, saving to a database, sending an email) and the caller only needs a success/failure signal. There is no meaningful data to pass back — only whether the operation worked.
Use DataAndMsgReturn when your function computes or fetches something the caller will consume. The data field carries the payload, msg gives a human-readable summary, and ok/error still handle the failure path — all in one object.
Without BasicReturns vs With BasicReturns
The comparison below shows the same “divide two numbers” operation written both ways. Notice how the ad-hoc version forces callers to know implementation details (catch the exception? check forNone? unpack the tuple?), while the BasicReturns version gives a single, uniform interface.
Key Benefits
Consistent error handling — every function speaks the same language. No more guessing whether to catch an exception, check for
None, or unpack a tuple.No unhandled exceptions leaking to callers — errors are captured in the error field and surfaced through ok = False, keeping control flow explicit and predictable.Full type safety — both models carry complete type annotations and are fully compatible with MyPy, so your static analysis tooling can verify return types across your project.Pydantic v2 foundation — built on pydantic==2.12.5, giving you runtime field validation, easy model composition, and .model_dump() interoperability alongside the built-in to_dict() method.Serialization included — call result.to_dict() on any return object to get a plain Python dict ready for JSON encoding, API responses, or logging.Python 3.8+ support — compatible with Python 3.8, 3.9, 3.10, 3.11, and 3.12.Package Details
| Property | Value |
|---|---|
| PyPI name | BasicReturns |
| Version | 0.1.1 |
| License | MIT |
| Python | >= 3.8 |
| Dependency | pydantic==2.12.5 |
| PyPI URL | pypi.org/project/BasicReturns |
| Source | github.com/Dev2Forge/BasicReturns |