[Python-Dev] email package status in 3.X

[Stephen J. Turnbull]

P.J. Eby writes:

 > Note too that this is an argument for symmetry in wrapping the
 > inputs and outputs, so that the code doesn't have to "know" what
 > it's dealing with!

and

 > After all, right now, if a stdlib function might return bytes or 
 > unicode depending on runtime conditions, I can't even hardcode an 
 > .encode() call -- it would fail if the return type is a bytes.

I'm lost.  What stdlib functions are you talking about whose return
type depends on runtime conditions, and what runtime conditions?  What
do you mean by "wrapping"?

The only times I've run into str/bytes nondeterminancy is when I've
mixed str/bytes myself, and passed them into functions that are
type-identities (str -> str, bytes -> bytes), which then appear to
give a nondeterministic result.  It's a deterministic bug, though,
always mine.<wink>

 > It's One Obvious Way that I want, but some people seem to be arguing 
 > that the One Obvious Way is to Think Carefully About It Every Time -- 
 > and that seems to violate the "Obvious" part, IMO.  ;-)

Nick alluded to the The One Obvious Way as a change in architecture.

Specifically: Decode all bytes to typed objects (str, images, audio,
structured objects) at input.  Do no manipulations on bytes ever
except decode and encode (both to text, and to special-purpose objects
such as images) in a program that does I/O.  (Obviously image
manipulation libraries etc will have to operate on bytes, but they
should have no functions that consume bytes except constructors a la
bytes.decode() for text, and no functions that produce bytes except
the output serializers that write files and the like, a la
str.encode().)  Encode back to bytes on output.

Yes, this is tedious if you live in an ASCII world, compared to using
bytes as characters.  However, it works for the rest of us, which the
old style doesn't.

As for "Think Carefully About It Every Time", that is required only in
Porting Programs That Mix Operation On Bytes With Operation On Str.
If you write programs from scratch, however, the decode-process-encode
paradigm quickly becomes second nature.