Message70967
| Author |
mgiuca |
| Recipients |
loewis, mgiuca, orsenthil |
| Date |
2008年08月10日.08:37:33 |
| SpamBayes Score |
7.8079975e-05 |
| Marked as misclassified |
No |
| Message-id |
<1218357456.16.0.0408878914182.issue3532@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> 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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2008年08月10日 08:37:36 | mgiuca | set | recipients:
+ mgiuca, loewis, orsenthil |
| 2008年08月10日 08:37:36 | mgiuca | set | messageid: <1218357456.16.0.0408878914182.issue3532@psf.upfronthosting.co.za> |
| 2008年08月10日 08:37:34 | mgiuca | link | issue3532 messages |
| 2008年08月10日 08:37:33 | mgiuca | create |
|