Provider Launchpad appears to be down

classification
Title: bytes.tohex method
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: duplicate
Dependencies: Superseder: codecs missing: base64 bz2 hex zlib hex_codec ...
View: 7475
Assigned To: Nosy List: BreamoreBoy, ajaksu2, eric.araujo, georg.brandl, lemburg, loewis, mgiuca, orsenthil, r.david.murray
Priority: normal Keywords: patch

Created on 2008-08-09 16:28 by mgiuca, last changed 2010-09-27 19:56 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
bytes.tohex.patch mgiuca, 2008-08-09 16:28 Patch adding "tohex" method.
Messages (19)
msg70932 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-09 16:28
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.
msg70944 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-08-09 17:36
I recommend to use binascii.hexlify; this works in all Python version
(since 2000 or so).

I'm -1 for this patch.
msg70948 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-09 18:25
> 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).
msg70950 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-08-09 18:44
> * 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.
msg70957 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-10 02:47
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.
msg70961 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-08-10 06:49
> 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.
msg70966 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2008-08-10 08:15
* 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.
msg70967 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-10 08:37
> 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.
msg70974 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-08-10 12:20
This is why we will get transform() and untransform() in 3.1.
msg70975 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-10 12:22
Oh, where's the information on those?

(A brief search of the peps and bug tracker shows nothing).
msg70978 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-08-10 12:26
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
msg70979 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-10 12:31
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?
msg70980 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-08-10 12:42
They are meant to replace encode/decode for those 2.x codecs that didn't
really encode/decode Unicode.
msg70981 - (view) Author: Matt Giuca (mgiuca) Date: 2008-08-10 12:45
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.
msg87930 - (view) Author: Daniel Diniz (ajaksu2) (Python triager) Date: 2009-05-16 20:55
Looks like transform/untransform went nowhere?
msg110681 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-18 20:21
This should be closed unless someone can provide a good reason for keeping it open.
msg111525 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-25 08:43
Closing as no response to msg110681.
msg112172 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-31 17:36
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 :)
msg117466 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-27 19:56
See #9951 for a patch adding bytes.hex
History
Date User Action Args
2010-09-27 19:56:17eric.araujosetmessages: + msg117466
2010-08-10 22:14:44eric.araujosetnosy: + eric.araujo
2010-07-31 17:44:57floxsetresolution: duplicate
superseder: codecs missing: base64 bz2 hex zlib hex_codec ...
2010-07-31 17:36:12r.david.murraysetnosy: + r.david.murray
messages: + msg112172
2010-07-25 08:43:45BreamoreBoysetstatus: pending -> closed

messages: + msg111525
2010-07-18 20:21:45BreamoreBoysetstatus: open -> pending
nosy: + BreamoreBoy
messages: + msg110681

2009-05-16 20:55:58ajaksu2setpriority: normal
versions: + Python 3.2, - Python 3.1
nosy: + ajaksu2, lemburg

messages: + msg87930

stage: patch review
2008-08-10 12:45:14mgiucasetmessages: + msg70981
2008-08-10 12:42:51georg.brandlsetmessages: + msg70980
2008-08-10 12:31:46mgiucasetmessages: + msg70979
2008-08-10 12:26:22georg.brandlsetmessages: + msg70978
2008-08-10 12:22:18mgiucasetmessages: + msg70975
2008-08-10 12:20:31georg.brandlsetnosy: + georg.brandl
messages: + msg70974
2008-08-10 08:37:34mgiucasetmessages: + msg70967
2008-08-10 08:15:01orsenthilsetnosy: + orsenthil
messages: + msg70966
2008-08-10 06:49:38loewissetmessages: + msg70961
2008-08-10 02:47:48mgiucasetmessages: + msg70957
2008-08-09 18:44:44loewissetversions: + Python 3.1, - Python 3.0
2008-08-09 18:44:27loewissetmessages: + msg70950
2008-08-09 18:25:15mgiucasetmessages: + msg70948
2008-08-09 17:36:12loewissetnosy: + loewis
messages: + msg70944
2008-08-09 16:28:46mgiucacreate