[issue3532] bytes.tohex method

[Éric Araujo]

Éric Araujo  added the comment:

See #9951 for a patch adding bytes.hex

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Florent Xicluna]

Changes by Florent Xicluna :


--
resolution:  -> duplicate
superseder:  -> codecs missing: base64 bz2 hex zlib hex_codec ...

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[R. David Murray]

R. David Murray  added the comment:

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

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Mark Lawrence]

Mark Lawrence  added the comment:

Closing as no response to msg110681.

--
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Mark Lawrence]

Mark Lawrence  added the comment:

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

--
nosy: +BreamoreBoy
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Daniel Diniz]

Daniel Diniz  added the comment:

Looks like transform/untransform went nowhere?

--
nosy: +ajaksu2, lemburg
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

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.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

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?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

Oh, where's the information on those?

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

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

--
nosy: +georg.brandl

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

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

--
nosy: +orsenthil

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

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.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Martin v. Löwis]

Changes by Martin v. Löwis <[EMAIL PROTECTED]>:


--
versions: +Python 3.1 -Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

Matt Giuca <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

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

I'm -1 for this patch.

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3532] bytes.tohex method

[Matt Giuca]

New submission from Matt Giuca <[EMAIL PROTECTED]>:

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.

--
components: Interpreter Core
files: bytes.tohex.patch
keywords: patch
messages: 70932
nosy: mgiuca
severity: normal
status: open
title: bytes.tohex method
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11091/bytes.tohex.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com