On 10.06.10 21:31, Terry Reedy wrote:
> On 6/10/2010 7:08 AM, M.-A. Lemburg wrote:
>> Walter Dörwald wrote:
>
The PEP would also serve as a reference back to both this discussion and
the previous one (which was long enough ago that I've forgotten most of
it).
>>>
>>> I too think t
On 6/10/2010 7:08 AM, M.-A. Lemburg wrote:
Walter Dörwald wrote:
The PEP would also serve as a reference back to both this discussion and
the previous one (which was long enough ago that I've forgotten most of it).
I too think that a PEP is required here.
Fair enough. I'll write a PEP.
T
On Thu, 10 Jun 2010 12:27:33 +0200, Baptiste Carvello
wrote:
> Victor Stinner wrote:
>
> > I suppose that each codec will have a different list of accepted input and
> > output types. Example:
>
> >bz2: encode:bytes->bytes, decode:bytes->bytes
> >rot13: encode:str->str, decode:str->str
Le jeudi 10 juin 2010 12:30:01, Walter Dörwald a écrit :
> Codecs support several types of error handling that don't make sense for
> transform()/untransform(). What should 'abc'.decode('hex', 'replace')
> do?
You mean 'abc'.transform('hex', 'replace'), right?
Error handler is useful for encoding
Walter Dörwald wrote:
> On 09.06.10 14:47, Nick Coghlan wrote:
>
>> On 09/06/10 22:18, Victor Stinner wrote:
>>> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
No, .transform() and .untransform() will be interface to same-type
codecs, i.e. ones that convert bytes to bytes or
On 09.06.10 14:47, Nick Coghlan wrote:
> On 09/06/10 22:18, Victor Stinner wrote:
>> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
>>> No, .transform() and .untransform() will be interface to same-type
>>> codecs, i.e. ones that convert bytes to bytes or str to str. As with
>>> .encod
Victor Stinner a écrit :
I suppose that each codec will have a different list of accepted input and
output types. Example:
bz2: encode:bytes->bytes, decode:bytes->bytes
rot13: encode:str->str, decode:str->str
hex: encode:bytes->str, decode: str->bytes
A user point of view: please
Antoine Pitrou writes:
> In which cases is this true? Hex is rarely used for ASCII-encoding of
> binary data, precisely because its efficiency is poor.
MIME quoted-printable, URL-quoting, and XBM come to mind.
___
Python-Dev mailing list
Python-Dev@p
On Wed, 09 Jun 2010 22:13:28 +0200
"Martin v. Löwis" wrote:
> py> binascii.b2a_base64(b'foo')
> b'Zm9v\n'
> py> binascii.b2a_hex(b'foo')
> b'666f6f'
>
> Now, I'd admit that "b2a" may be a misnomer (binary -> ASCII), but then
> it may not because ASCII actually *also* implies "bytes" (it's an enco
But in both cases you probably want bytes -> bytes and str -> str. If
you want text out then put text in, if you want bytes out then put bytes in.
No, I don't think so. If I'm using hex "encoding", it's because I want
to see a text representation of some arbitrary bytestring (in order to
displ
On Wed, 09 Jun 2010 15:45:55 -0400
Terry Reedy wrote:
> On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
> > On Wed, 9 Jun 2010 13:57:05 +0200
> > Dirkjan Ochtman wrote:
> >> On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> >>> No, I don't think so. If I'm using hex "encoding", it's because I wan
On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtman wrote:
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
No, I don't think so. If I'm using hex "encoding", it's because I want
to see a text representation of some arbitrary bytestring (in order to
On 6/9/2010 7:45 AM, M.-A. Lemburg wrote:
Nick Coghlan wrote:
On 09/06/10 18:41, M.-A. Lemburg wrote:
The methods to be used will be .transform() for the encode direction
and .untransform() for the decode direction.
+1, although adding this for 3.2 would need an exception to the
moratorium ap
On Wed, 09 Jun 2010 16:35:38 +0200, Victor Stinner
wrote:
> Le mercredi 09 juin 2010 14:47:22, Nick Coghlan a =E9crit :
> > *Some are obvious, such as rot13 being text only,
>
> Should rot13 shift any unicode character, or just a-z and A-Z?
The latter, unless you want to do a lot of work:
Antoine Pitrou wrote:
> Le mercredi 09 juin 2010 à 12:38 +0100, Michael Foord a écrit :
> > On 09/06/2010 12:35, Antoine Pitrou wrote:
> > > On Wed, 09 Jun 2010 10:41:29 +0200
> > > "M.-A. Lemburg" wrote:
> > >
> > >> The above example will read:
> > >>
> > >> >>> b'abc'.transform("hex
Le mercredi 09 juin 2010 14:47:22, Nick Coghlan a écrit :
> *Some are obvious, such as rot13 being text only,
Should rot13 shift any unicode character, or just a-z and A-Z?
Python2 only changes characters a-z and A-Z, and use ISO-8859-1 to encode
unicode to byte string.
>>> u"abc é".encode("rot
On 09/06/10 22:18, Victor Stinner wrote:
Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
No, .transform() and .untransform() will be interface to same-type
codecs, i.e. ones that convert bytes to bytes or str to str. As with
.encode()/.decode() these helper methods also implement type
Victor Stinner wrote:
> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
>> No, .transform() and .untransform() will be interface to same-type
>> codecs, i.e. ones that convert bytes to bytes or str to str. As with
>> .encode()/.decode() these helper methods also implement type safety
>>
Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
> No, .transform() and .untransform() will be interface to same-type
> codecs, i.e. ones that convert bytes to bytes or str to str. As with
> .encode()/.decode() these helper methods also implement type safety
> of the return type.
What ab
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtman wrote:
> On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> > No, I don't think so. If I'm using hex "encoding", it's because I want
> > to see a text representation of some arbitrary bytestring (in order to
> > display it inside another piece
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> No, I don't think so. If I'm using hex "encoding", it's because I want
> to see a text representation of some arbitrary bytestring (in order to
> display it inside another piece of text, for example).
> In other words, the purpose of hex is pre
Antoine Pitrou wrote:
> On Wed, 09 Jun 2010 10:41:29 +0200
> "M.-A. Lemburg" wrote:
>>
>> The above example will read:
>>
>> >>> b'abc'.transform("hex")
>> b'616263'
>> >>> b'616263'.untranform("hex")
>> b'abc'
>
> This doesn't look right to me. Hex-encoded "data" is really text (
Nick Coghlan wrote:
> On 09/06/10 18:41, M.-A. Lemburg wrote:
>> The methods to be used will be .transform() for the encode direction
>> and .untransform() for the decode direction.
>
> +1, although adding this for 3.2 would need an exception to the
> moratorium approved (since it is adding new me
On Wed, 09 Jun 2010 21:14:33 +1000, Nick Coghlan wrote:
> On 09/06/10 18:41, M.-A. Lemburg wrote:
> > The methods to be used will be .transform() for the encode direction
> > and .untransform() for the decode direction.
>
> +1, although adding this for 3.2 would need an exception to the
> morato
Le mercredi 09 juin 2010 à 12:38 +0100, Michael Foord a écrit :
> On 09/06/2010 12:35, Antoine Pitrou wrote:
> > On Wed, 09 Jun 2010 10:41:29 +0200
> > "M.-A. Lemburg" wrote:
> >
> >> The above example will read:
> >>
> >> >>> b'abc'.transform("hex")
> >> b'616263'
> >> >>> b'
On 09/06/2010 12:35, Antoine Pitrou wrote:
On Wed, 09 Jun 2010 10:41:29 +0200
"M.-A. Lemburg" wrote:
The above example will read:
>>> b'abc'.transform("hex")
b'616263'
>>> b'616263'.untranform("hex")
b'abc'
This doesn't look right to me. Hex-encoded "data" is r
On Wed, 09 Jun 2010 10:41:29 +0200
"M.-A. Lemburg" wrote:
>
> The above example will read:
>
> >>> b'abc'.transform("hex")
> b'616263'
> >>> b'616263'.untranform("hex")
> b'abc'
This doesn't look right to me. Hex-encoded "data" is really text (it's
a textual representation of bi
On 09/06/10 18:41, M.-A. Lemburg wrote:
The methods to be used will be .transform() for the encode direction
and .untransform() for the decode direction.
+1, although adding this for 3.2 would need an exception to the
moratorium approved (since it is adding new methods for builtin types).
Ad
Victor Stinner wrote:
> There are two opposite issues in the bug tracker:
>
>#7475: codecs missing: base64 bz2 hex zlib ...
>-> reintroduce the codecs removed from Python3
>
>#8838: Remove codecs.readbuffer_encode()
>-> remove the last part of the removed codecs
>
> If I understo
There are two opposite issues in the bug tracker:
#7475: codecs missing: base64 bz2 hex zlib ...
-> reintroduce the codecs removed from Python3
#8838: Remove codecs.readbuffer_encode()
-> remove the last part of the removed codecs
If I understood correctly, the question is: should co
30 matches
Mail list logo
