Skip to content

Conversation

doubledare704
Copy link

@doubledare704 doubledare704 commented Apr 3, 2025

  • 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 svlandeg added the feature New feature, enhancement or request label Apr 4, 2025
@svlandeg svlandeg changed the title [Implementation] Support for bytes in Options and Arguments ✨ Support bytes in Options and Arguments Apr 4, 2025
@svlandeg
Copy link
Member

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 🙏

Copy link

@YuriiMotov YuriiMotov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link

@saky-semicolon saky-semicolon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

…ng-aware BytesParamType with helpers\n- Wire ParameterInfo.encoding/errors through Argument/Option\n- Add edge-case tests (non-ASCII, latin-1, ascii+errors, invalid encodings)\n- Expand examples to demonstrate encoding and errors\n- Add docs page: Tutorial -> CLI Parameter Types -> Bytes; wire into nav\n\nBackwards compatible: defaults to UTF-8 + 'strict' when not specified.
@doubledare704
Copy link
Author

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!

Copy link
Contributor

- Update test to assert error message in `stderr` instead of `stdout`.
- Adjust indentation for function parameters to improve readability.
Copy link
Contributor

- Update test to assert error message in `stderr` instead of `stdout`.
- Adjust indentation for function parameters to improve readability.
Copy link
Contributor

- Update test to assert error message in `stderr` instead of `stdout`.
- Adjust indentation for function parameters to improve readability.
Copy link
Contributor

- Update test to assert error message in `stderr` instead of `stdout`.
- Adjust indentation for function parameters to improve readability.
Copy link
Contributor

Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature, enhancement or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants