bytes.tohex method #47782

mgiuca · 2008-08-09T16:28:47Z

BPO	3532
Nosy	@malemburg, @loewis, @birkenfeld, @orsenthil, @devdanzin, @merwok, @bitdancer
Superseder	bpo-7475: codecs missing: base64 bz2 hex zlib hex_codec ...
Files	bytes.tohex.patch: Patch adding "tohex" method.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-07-25.08:43:45.359>
created_at = <Date 2008-08-09.16:28:46.649>
labels = ['interpreter-core', 'type-feature']
title = 'bytes.tohex method'
updated_at = <Date 2010-09-27.19:56:17.183>
user = 'https://bugs.python.org/mgiuca'

bugs.python.org fields:

activity = <Date 2010-09-27.19:56:17.183>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = <Date 2010-07-25.08:43:45.359>
closer = 'BreamoreBoy'
components = ['Interpreter Core']
creation = <Date 2008-08-09.16:28:46.649>
creator = 'mgiuca'
dependencies = []
files = ['11091']
hgrepos = []
issue_num = 3532
keywords = ['patch']
message_count = 19.0
messages = ['70932', '70944', '70948', '70950', '70957', '70961', '70966', '70967', '70974', '70975', '70978', '70979', '70980', '70981', '87930', '110681', '111525', '112172', '117466']
nosy_count = 9.0
nosy_names = ['lemburg', 'loewis', 'georg.brandl', 'orsenthil', 'ajaksu2', 'eric.araujo', 'mgiuca', 'r.david.murray', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'patch review'
status = 'closed'
superseder = '7475'
type = 'enhancement'
url = 'https://bugs.python.org/issue3532'
versions = ['Python 3.2']

mgiuca · 2008-08-09T16:28:40Z

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.

loewis · 2008-08-09T17:36:12Z

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

I'm -1 for this patch.

mgiuca · 2008-08-09T18:25:14Z

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).

loewis · 2008-08-09T18:44:27Z

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.

mgiuca · 2008-08-10T02:47:47Z

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.

loewis · 2008-08-10T06:49:38Z

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.

orsenthil · 2008-08-10T08:15:01Z

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.

mgiuca · 2008-08-10T08:37:34Z

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.

birkenfeld · 2008-08-10T12:20:31Z

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

mgiuca · 2008-08-10T12:22:18Z

Oh, where's the information on those?

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

birkenfeld · 2008-08-10T12:26:23Z

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

mgiuca · 2008-08-10T12:31:46Z

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?

birkenfeld · 2008-08-10T12:42:51Z

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

mgiuca · 2008-08-10T12:45:14Z

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.

devdanzin · 2009-05-16T20:55:58Z

Looks like transform/untransform went nowhere?

BreamoreBoy · 2010-07-18T20:21:45Z

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

BreamoreBoy · 2010-07-25T08:43:45Z

Closing as no response to msg110681.

bitdancer · 2010-07-31T17:36:12Z

The 'add transform/untransform' issue seems to be bpo-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 :)

merwok · 2010-09-27T19:56:17Z

See bpo-9951 for a patch adding bytes.hex

mgiuca mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Aug 9, 2008

BreamoreBoy mannequin closed this as completed Jul 25, 2010

ezio-melotti transferred this issue from another repository Apr 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bytes.tohex method #47782

bytes.tohex method #47782

mgiuca mannequin commented Aug 9, 2008

mgiuca mannequin commented Aug 9, 2008

loewis mannequin commented Aug 9, 2008

mgiuca mannequin commented Aug 9, 2008

loewis mannequin commented Aug 9, 2008

mgiuca mannequin commented Aug 10, 2008

loewis mannequin commented Aug 10, 2008

orsenthil commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

birkenfeld commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

birkenfeld commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

birkenfeld commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

devdanzin mannequin commented May 16, 2009

BreamoreBoy mannequin commented Jul 18, 2010

BreamoreBoy mannequin commented Jul 25, 2010

bitdancer commented Jul 31, 2010

merwok commented Sep 27, 2010

bytes.tohex method #47782

bytes.tohex method #47782

Comments

mgiuca mannequin commented Aug 9, 2008

mgiuca mannequin commented Aug 9, 2008

loewis mannequin commented Aug 9, 2008

mgiuca mannequin commented Aug 9, 2008

loewis mannequin commented Aug 9, 2008

mgiuca mannequin commented Aug 10, 2008

loewis mannequin commented Aug 10, 2008

orsenthil commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

birkenfeld commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

birkenfeld commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

birkenfeld commented Aug 10, 2008

mgiuca mannequin commented Aug 10, 2008

devdanzin mannequin commented May 16, 2009

BreamoreBoy mannequin commented Jul 18, 2010

BreamoreBoy mannequin commented Jul 25, 2010

bitdancer commented Jul 31, 2010

merwok commented Sep 27, 2010