I haven't been able to find a way to encode a bytes object in
hexadecimal, where in Python 2.x I'd go "str.encode('hex')".

I recommend adding a bytes.tohex() method (in the same vein as the
existing bytes.fromhex class method).

I've attached a patch which adds this method to the bytes and bytearray
classes (in the C code). Also included documentation and test cases.

Style note: The bytesobject.c and bytearrayobject.c files are all over
the place in terms of tabs/spaces. I used tabs in bytesobject and spaces
in bytearrayobject, since those seemed to be the predominant styles in
either file.

Commit log:

Added "tohex" method to bytes and bytearray objects. Also added
documentation and test cases.

I recommend to use binascii.hexlify; this works in all Python version
(since 2000 or so).

I'm -1 for this patch.

> I recommend to use binascii.hexlify.

Ah, see I did not know about this! Thanks for pointing it out.

* However, it is *very* obscure. I've been using Python for a year and I
didn't know about it.
* And, it requires importing binascii.
* And, it results in a bytes object, not a str. That's weird. (Perhaps
it would be good idea to change the functions in the binascii module to
output strings instead of bytes? Ostensibly it looks like this module
hasn't undergone py3kification).

Would it hurt to have the tohex method of the bytes object to perform
this task as well? It would be much nicer to use since it's a method of
the object rather than having to find out about and import and use some
function.

Also why have a bytes.fromhex method when you could use binascii.unhexlify?

(If it's better from a code standpoint, you could replace the code I
wrote with a call to binascii.unhexlify).

> * However, it is *very* obscure. I've been using Python for a year and I
> didn't know about it.

Hmm. There are probably many modules that you haven't used yet.

> * And, it requires importing binascii.

So what? The desire to convert bytes into hex strings is infrequent
enough to leave it out of the realm of a method. Also, Guido has
pronounced that he prefers functions over methods (and in this case,
I agree)

Using functions is more extensible. If you wanted to produce base-85
(say), then you can extend the functionality of bytes by providing a
function that does that, whereas you can't extend the existing bytes
type.

> * And, it results in a bytes object, not a str. That's weird. (Perhaps
> it would be good idea to change the functions in the binascii module to
> output strings instead of bytes? Ostensibly it looks like this module
> hasn't undergone py3kification).

There has been endless debates on this (or, something similar to this),
revolving around the question: "is base-64 text or binary"?

> Would it hurt to have the tohex method of the bytes object to perform
> this task as well?

IMO, yes, it would. It complicates the code, and draws the focus away
from the proper approach to data conversion (namely, functions - not
methods).

> It would be much nicer to use since it's a method of
> the object rather than having to find out about and import and use some
> function.

That's highly debatable.

> Also why have a bytes.fromhex method when you could use binascii.unhexlify?

Good point.

In any case, this is my opion; feel free to discuss this on python-dev.

Very clearly it is too late to add this for 3.0 now.

You did the 3.1 thing again! We can accept a new feature like this
before 3.0b3, can we not?

> Hmm. There are probably many modules that you haven't used yet.

Snap :)

Well, I didn't know about the community's preference for functions over
methods. You make a lot of good points.

I think the biggest problem I have is the existence of fromhex. It's
really strange/inconsistent to have a fromhex without a tohex.

Also I think a lot of people (like me, in my relative inexperience) are
going to be at a loss as to why .encode('hex') went away, and they'll
easily be able to find .tohex (by typing help(bytes), or just guessing),
while binascii.hexlify is sufficiently obscure that I had to ask.

> You did the 3.1 thing again! We can accept a new feature like this
> before 3.0b3, can we not?

Not without explicit approval by the release manager, no (or by BDFL
pronouncement).

The point of the betas is that *only* bugs get fixed, and *no* new
are features added.

* scriptor Matt Giuca, explico 
> 
> I think the biggest problem I have is the existence of fromhex. It's
> really strange/inconsistent to have a fromhex without a tohex.

Except, when we look at the context. This is bytes class
method returns a bytes or bytearray object, decoding the given string object.

Do we require an opposite in the bytes class method? Where will we use it?
> 
> Also I think a lot of people (like me, in my relative inexperience) are
> going to be at a loss as to why .encode('hex') went away, and they'll

No, it is not going away. str.encode('hex') is available to users when they
seek it. They wont look for it under bytes type.

> Except, when we look at the context. This is bytes class
> method returns a bytes or bytearray object, decoding the given
> string object.

> Do we require an opposite in the bytes class method? Where will
> we use it?
No, tohex is not a class method (unlike fromhex). It's just a regular
method on the bytes object.

> No, it is not going away. str.encode('hex') is available to
> users when they seek it. They wont look for it under bytes type.

>>> 'hello'.encode('hex')
LookupError: unknown encoding: hex

This is deliberate, I'm pretty sure. encode/decode are for converting
to/from unicode strings and bytes. It never made sense to have "hex" in
there, which actually goes the other way. And it makes no sense to
encode a Unicode string as hex (since they aren't bytes). So it's good
that that went away.

I'm just saying it should have something equally accessible to replace it.

This is why we will get transform() and untransform() in 3.1.

Oh, where's the information on those?

(A brief search of the peps and bug tracker shows nothing).

At the moment, mails on python-dev are the only source of information :)

Look here:
http://mail.python.org/pipermail/python-3000/2008-August/014533.html

OK thanks.

Well I still can't really see what transform/untransform are about. Is
it OK to keep this issue open (and listed as 3.1) until more information
becomes available on those methods?

They are meant to replace encode/decode for those 2.x codecs that didn't
really encode/decode Unicode.

So I assumed.

In that case, why is there a "fromhex"? (Was that put in there before
the notion of transform/untransform?) As I've been saying, it's weird to
have a fromhex but not a tohex.

Anyway, assuming we go to 3.1 and add transform/untransform, I suppose
fromhex will remain for backwards, and tohex will not be needed. So I
guess this issue is closed.

Looks like transform/untransform went nowhere?

This should be closed unless someone can provide a good reason for keeping it open.

Closing as no response to msg110681.

The 'add transform/untransform' issue seems to be issue 7475.

Note that there was in fact supposed to be a 'hex' method:

http://mail.python.org/pipermail/python-dev/2009-September/091628.html

Matt, if you'd like to raise this question again on python-dev, maybe your patch could be used to add it, in which case we could reopen this issue.  Or we can wait for transform/untransform and just ignore the existence of fromhex :)

See #9951 for a patch adding bytes.hex