[issue3532] bytes.tohex method

Éric Araujo added the comment: See #9951 for a patch adding bytes.hex -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue3532] bytes.tohex method

Changes by Éric Araujo : -- nosy: +merwok ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue3532] bytes.tohex method

Changes by Florent Xicluna : -- resolution: -> duplicate superseder: -> codecs missing: base64 bz2 hex zlib hex_codec ... ___ Python tracker ___

[issue3532] bytes.tohex method

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, ma

[issue3532] bytes.tohex method

Mark Lawrence added the comment: Closing as no response to msg110681. -- status: pending -> closed ___ Python tracker ___ ___ Python-b

[issue3532] bytes.tohex method

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 ___

[issue3532] bytes.tohex method

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 __

[issue3532] bytes.tohex method

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/untransf

[issue3532] bytes.tohex method

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]> ___

[issue3532] bytes.tohex method

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

[issue3532] bytes.tohex method

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

[issue3532] bytes.tohex method

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]> _

[issue3532] bytes.tohex method

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]> ___

[issue3532] bytes.tohex method

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 m

[issue3532] bytes.tohex method

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 byte

[issue3532] bytes.tohex method

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

[issue3532] bytes.tohex method

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 metho

[issue3532] bytes.tohex method

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- versions: +Python 3.1 -Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue3532] bytes.tohex method

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 byte

[issue3532] bytes.tohex method

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

[issue3532] bytes.tohex method

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

[issue3532] bytes.tohex method

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