0.17.1 (2024-01-04)

Features

Export Unset types from generated types.py (#927)

Generate properties for some boolean enums

If a schema has both type = "boolean" and enum defined, a normal boolean property will now be created.
Previously, the generator would error.

Note that the generate code will not correctly limit the values to the enum values. To work around this, use the
OpenAPI 3.1 const instead of enum to generate Python Literal types.

Thanks for reporting #922 @macmoritz!

Fixes

Do not stop generation for invalid enum values

This generator only supports enum values that are strings or integers.
Previously, this was handled at the parsing level, which would cause the generator to fail if there were any unsupported values in the document.
Now, the generator will correctly keep going, skipping only endpoints which contained unsupported values.

Thanks for reporting #922 @macmoritz!

Fix lists within unions

Fixes #756 and #928. Arrays within unions (which, as of 0.17 includes nullable arrays) would generate invalid code.

Thanks @kgutwin and @diesieben07!

Simplify type checks for non-required unions

0.17.0 (2023-12-31)

Breaking Changes

Removed query parameter nullable/required special case

In previous versions, setting either nullable: true or required: false on a query parameter would act like both were set, resulting in a type signature like Union[None, Unset, YourType]. This special case has been removed, query parameters will now act like all other types of parameters.

Renamed body types and parameters

PR #900 addresses #822.

Where previously there would be one body parameter per supported content type, now there is a single body parameter which takes a union of all the possible inputs. This correctly models the fact that only one body can be sent (and ever would be sent) in a request.

For example, when calling a generated endpoint, code which used to look like this:

post_body_multipart.sync_detailed(
client=client,
multipart_data=PostBodyMultipartMultipartData(),
)

Will now look like this:

post_body_multipart.sync_detailed(
client=client,
body=PostBodyMultipartBody(),
)

Note that both the input parameter name and the class name have changed. This should result in simpler code when there is only a single body type and now produces correct code when there are multiple body types.

Features

OpenAPI 3.1 support

The generator will now attempt to generate code for OpenAPI documents with versions 3.1.x (previously, it would exit immediately on seeing a version other than 3.0.x). The following specific OpenAPI 3.1 features are now supported:

• null as a type
• Arrays of types (e.g., type: [string, null])
• const (defines Literal types)

The generator does not currently validate that the OpenAPI document is valid for a specific version of OpenAPI, so it may be possible to generate code for documents that include both removed 3.0 syntax (e.g., nullable) and new 3.1 syntax (e.g., null as a type).

Thanks to everyone who helped make this possible with discussions and testing, including:

• @frco9
• @vogre
• @naddeoa
• @staticdev
• @philsturgeon
• @johnthagen

Support multiple possible requestBody

PR #900 addresses #822.

It is now possible in some circumstances to generate valid code for OpenAPI documents which have multiple possible requestBody values. Previously, invalid code could have been generated with no warning (only one body could actually be sent).

Only one content type per "category" is currently supported at a time. The categories are:

• JSON, like application/json
• Binary data, like application/octet-stream
• Encoded form data, like application/x-www-form-urlencoded
• Files, like multipart/form-data

Fixes

Always use correct content type for requests

In previous versions, a request body that was similar to a known content type would use that content type in the request. For example application/json would be used for application/vnd.api+json. This was incorrect and could result in invalid requests being sent.

Now, the content type defined in the OpenAPI document will always be used.

0.16.1 (2023-12-23)

Features

Support httpx 0.26 (#913)

0.16.0 (2023-12-07)

Breaking Changes

Switch from Black to Ruff for formatting

black is no longer a runtime dependency, so if you have them set in custom post_hooks in a config file, you'll need to make sure they're being installed manually. ruff is now installed and used by default instead.

Use Ruff instead of isort + autoflake at runtime

isort and autoflake are no longer runtime dependencies, so if you have them set in custom post_hooks in a config file, you'll need to make sure they're being installed manually. ruff is now installed and used by default instead.

Features

Support all text/* content types in responses

Within an API response, any content type which starts with text/ will now be treated the same as text/html already was—they will return the response.text attribute from the httpx Response.

Thanks to @fdintino for the initial implementation, and thanks for the discussions from @kairntech, @rubenfiszel, and @antoneladestito.

Closes #797 and #821.

Support application/octet-stream request bodies

Endpoints that accept application/octet-stream request bodies are now supported using the same File type as octet-stream responses.

Thanks to @kgutwin for the implementation and @rtaycher for the discussion!

PR #899 closes #588

Fixes

Remove useless pass statements from generated code

0.15.2 (2023-09-16)

Features

support httpx 0.25 (#854)

Support content-type with attributes (#655, #809, #858). Thanks @sherbang!

0.15.1 (2023-08-12)

Features

Upgrade internal Pydantic use to v2. Thanks @KristinnVikar! (#779)

Fixes

Naming conflicts when properties are named "field" or "define" (#781, #793). Thanks @david-dotorigin

0.15.0 (2023-07-23)

Breaking Changes

Minimum httpx version raised to 0.20

Some features of generated clients already failed at runtime when using httpx < 0.20, but now the minimum version is enforced at generation time.

Connections from clients no longer automatically close (PR #775)

Client and AuthenticatedClient now reuse an internal httpx.Client (or AsyncClient)—keeping connections open between requests. This will improve performance overall, but may cause resource leaking if clients are not closed properly. The new clients are intended to be used via context managers—though for compatibility they don't have to be used with context managers. If not using a context manager, connections will probably leak. Note that once a client is closed (by leaving the context manager), it can no longer be used—and attempting to do so will raise an exception.

APIs should now be called like:

with client as client:
    my_api.sync(client)
    another_api.sync(client)
# client is closed here and can no longer be used

Generated READMEs reflect the new syntax, but READMEs for existing generated clients should be updated manually. See this diff for inspiration.

Generated clients and models now use the newer attrs @define and field APIs

See the attrs docs for more information on how these may affect you.

Removed public attributes for Client and AuthenticatedClient

The following attributes have been removed from Client and AuthenticatedClient:

• base_url—this can now only be set via the initializer
• cookies—set at initialization or use .with_cookies()
• headers—set at initialization or use .with_headers()
• timeout—set at initialization or use .with_timeout()
• verify_ssl—this can now only be set via the initializer
• follow_redirects—this can now only be set via the initializer

The timeout param and with_timeout now take an httpx.Timeout instead of a float

AuthenticatedClient no longer inherits from Client

The API of AuthenticatedClient is still a superset of Client, but the two classes no longer share a common base class.

Features

Allow customizing the underlying httpx clients

There are many use-cases where customizing the underlying httpx client directly is necessary. Some examples are:

• Event hooks
• Proxies
• Custom authentication
• Retries

The new Client and AuthenticatedClient classes come with several methods to customize underlying clients. You can pass arbitrary arguments to httpx.Client or httpx.AsyncClient when they are constructed:

client = Client(base_url="https://api.example.com", httpx_args={"proxies": {"https://": "https://proxy.example.com"}})

The underlying clients are constructed lazily, only when needed. httpx_args are stored internally in a dictionary until the first request is made.

You can force immediate construction of an underlying client in order to edit it directly:

import httpx
from my_api import Client

client = Client(base_url="https://api.example.com")
sync_client: httpx.Client = client.get_httpx_client()
sync_client.timeout = 10
async_client = client.get_async_httpx_client()
async_client.timeout = 15

You can also completely override the underlying clients:

import httpx
from my_api import Client

client = Client(base_url="https://api.example.com")
# The params you put in here ^ are discarded when you call set_httpx_client or set_async_httpx_client
sync_client = httpx.Client(base_url="https://api.example.com", timeout=10)
client.set_httpx_client(sync_client)
async_client = httpx.AsyncClient(base_url="https://api.example.com", timeout=15)
client.set_async_httpx_client(async_client)

Clients now reuse connections between requests

This happens every time you use the same Client or AuthenticatedClient instance for multiple requests, however it is best to use a context manager (e.g., with client as client:) to ensure the client is closed properly.

Fixes

Stop showing Poetry instructions in generated READMEs when not appropriate

0.14.1

0.14.1

Fixes

• Allow parameters named "client" and "url" [#758, #762, #765]. Thanks @truenicoco & @juanber84!

0.14.0

0.14.0

Breaking Changes

• Drop support for Python 3.7, put minimum version limit on Black (#754)

Features

• Better typing (mypy) support for Unset (e.g., using if statements to check type) [#714, #752]. Thanks @taasan & @mcclurem!
• pyproject_no_poetry.toml.jinja template can be used to configure black and isort [#750, #751]. Thanks @machinehead!

0.13.4

0.13.4

Features

• support httpx 0.24 (#746)