✨ Support bytes in Options and Arguments

[doubledare704]

• Added support for bytes type in Typer by:
• Creating a custom BytesParamType class in typer/main.py
• Modifying the get_click_type function to handle bytes type
• Created comprehensive tests:
  • Basic tests for bytes type in tests/test_bytes_type.py
  • Advanced tests for base64 and hex encoding/decoding in tests/test_bytes_encoding.py
• Created example applications:
  • Simple bytes example in examples/bytes_type_example.py
  • Comprehensive encoding/decoding example in examples/bytes_encoding_example.py

Attempt to solve #536

[svlandeg]

Thanks for the PR, appreciate the time and effort spent on writing tests as well!

We'll get this reviewed by the team and will get back to you 🙏

[YuriiMotov]

@doubledare704, thank you for your interest and efforts!

As I see it, the main reason to introduce bytes type support is to have the ability to use the same function outside the Typer, right?
Otherwise I don't see a point in this.. We can just accept str and decode it in one line. That would even be easier in cases where we want to let users specify the encoding as a CLI option

This implementation assumes that the argument value is encoded with system default encoding. It doesn't allow to specify the encoding.
This implementation assumes that the argument value is encoded with the system default encoding. It doesn’t allow specifying the encoding.
I believe we should at least allow specifying the encoding as a parameter to Argument/Option.

But first, I would wait for Sebastian to approve the idea

[saky-semicolon]

A few improvement opportunities:

Consider adding more edge case tests to further validate error handling.

In convert(), extracting decoding/encoding logic into helper functions could improve readability and reuse.

Documentation could be expanded with usage examples to make it easier for new users to try the features.

[doubledare704]

Summary of bytes support changes and request for approval

Primary use case:

• Allow the same function to work both inside Typer (CLI parsing) and outside Typer (regular Python code) with bytes parameters.

API and implementation:

• Reused existing ParameterInfo.encoding and ParameterInfo.errors to control how CLI inputs are encoded to bytes.
• Implemented encoding-aware BytesParamType(encoding=None, errors=None) with small helper methods for readability.
• Wiring: get_click_type(annotation is bytes) now returns a configured BytesParamType based on the Argument/Option’s encoding/errors. Defaults are UTF-8 + "strict", matching Python’s str.encode() behavior.
• Backward compatibility: unchanged when encoding/errors aren’t provided; typing bytes still works as before.

Tests:

• Added edge cases: non-ASCII defaults (UTF-8), latin-1 for Argument/Option, errors="replace" with ascii, invalid encoding name error messaging.
• Full test suite passes locally.

Docs/examples:

• New docs page: Tutorial → CLI Parameter Types → Bytes, with examples from docs_src.
• Updated examples to demonstrate default UTF-8, latin-1, ascii+replace.

Questions:

• Please confirm the approach of reusing ParameterInfo.encoding/errors for bytes and the default policy (UTF-8, "strict") is acceptable.
• If you prefer a different default or API shape, I’m happy to adjust.

Thanks!

[github-actions]

📝 Docs preview for commit 77c2846 at: https://5457df22.typertiangolo.pages.dev

Modified Pages

• https://5457df22.typertiangolo.pages.dev/tutorial/parameter-types/bytes/ - (before)

[svlandeg]

As a quick comment, if we do decide to progress with this PR, we should add the correct tests for the tutorial files in test_tutorial/test_parameter_types/test_bytes.

[doubledare704]

I've just added tests for tutorials. Please check.

[svlandeg]

This page should also be added to mkdocs.yml

[doubledare704]

seems like already has a link in mkdocs
mkdocs.yml:118

[github-actions]

📝 Docs preview

Last commit d86b0bd at: https://76abc87b.typertiangolo.pages.dev

Modified Pages

• https://76abc87b.typertiangolo.pages.dev/tutorial/parameter-types/bytes/ - (before)

[svlandeg]

@doubledare704: as Yurii said, we'll wait for further reviews until Tiangolo approves the idea. We have got this on our internal board, so no need for further pings 🙏