STY: Refactor b_

[j-t-1]

Comment courtesy of @shartzog, issue #2726.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.16%. Comparing base (b2d7204) to head (c22b6e2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2772      +/-   ##
==========================================
- Coverage   95.16%   95.16%   -0.01%     
==========================================
  Files          51       51              
  Lines        8548     8545       -3     
  Branches     1704     1703       -1     
==========================================
- Hits         8135     8132       -3     
  Misses        261      261              
  Partials      152      152              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stefan6419846]

I am not sure if this comment really is required here instead of just linking to the corresponding thread for example.

[j-t-1]

I wanted it self-contained, and not needing to refer externally. The comment contains all the information needed to understand why we are caching characters.

[pubpub-zz]

I'm not sure about the comment : When you "print" character per character they are all within the same content stream.

still not sure the caching is done the good way

[j-t-1]

@pubpub-zz I have removed the comment in b_ for now.

One idea is we could pre-compute the dictionary B_CACHE for the 256 values, using utf-8 as the encoding. So just have a lookup table and one if statement testing if the length of the string is one.

Also, how about a rename of b_ to bytes_ as this is more self-describing and would match the converse str_?