[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Cameron Simpson cs at zip.com.au
Sun Jan 12 03:05:04 CET 2014


On 11Jan2014 13:15, Juraj Sukop <juraj.sukop at gmail.com> wrote:
> On Sat, Jan 11, 2014 at 5:14 AM, Cameron Simpson <cs at zip.com.au> wrote:
> >   data = b' '.join( bytify( [ 10, 0, obj, binary_image_data, ... ] ) )
> 
> Thanks for the suggestion! The problem with "bytify" is that some items
> might require different formatting than other items. For example, in
> "Cross-Reference Table" there are three different formats: non-padded
> integer ("1"), 10- and 15digit integer, ("0000000003", "65535").

Well, this is partly my point: you probably want to exert more
control that is reasonable for the PEP to offer, and you're better
off with a helper function of your own. In particular, aside from
passing in a default char=>bytes encoding, you can provide your own
format hooks.

In particular, str already provides a completish % suite and you
have no issue with encodings in that phase because it is all Unicode.

So the points where you're treating PDF as text are probably best
tackled as text and then encoded with a helper like bytify when you
have to glom bytes and "textish" stuff together.

Crude example, hacked up from yours:

  data = b''.join( bytify(
    ("%d %d obj ... stream" % (10, 0)),
    binary_image_data,
    "endstream endobj",
  )))

where bytify swallows your encoding decisions.

Since encoding anything-not-bytes into a bytes sequence inherently
involves an encoding decision, I think I'm +1 on the PEP's aim of
never mixing bytes with non-bytes, keeping all the encoding decisions
in the caller's hands.

I quite understand not wanting to belabour the code with
".encode('ascii')" but that should be said somewhere, so best to
do so yourself in as compact and ergonomic fashion as possible.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au>

Serious error.
All shortcuts have disappeared.
Screen. Mind. Both are blank.
- Haiku Error Messages http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html


More information about the Python-Dev mailing list