[Python-3000] PEP 3138- String representation in Python 3000

Georg Brandl g.brandl at gmx.net
Wed May 14 18:33:41 CEST 2008


M.-A. Lemburg schrieb:
> On 2008-05-09 18:06, Guido van Rossum wrote:
>> On Fri, May 9, 2008 at 3:54 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>> On 2008-05-08 22:55, Terry Reedy wrote:
>>>> Functions that map unicode->unicode or bytes->bytes could be called
>>>> transcoders.  Each type could be given a .transcode method to go along with
>>>> but contrast with .encode or .decode.
>>> Are you suggesting to have two separate methods which then
>>> allow same-type-conversions ? One for encoding to the same
>>> type and one for decoding ?
>>>
>>> Fine with me.
>>>
>>> They do have to map naturally to the codec method encode and
>>> decode, though, so a single method won't do, unless maybe
>>> you add a parameter to define the direction of the coding
>>> process.
>>>
>>> In summary, I'd just like to see the following happen:
>>>
>>>  * revert the type restrictions on the PyCodec_* API
>>>
>>>  * enforce the restrictions on the .encode() and .decode()
>>>   methods of PyUnicode and PyString objects (str and bytes)
>>>
>>>  * add a way to PyUnicode and PyString objects (str and bytes)
>>>   to allow same type encoding and decoding
>> 
>> +1

Will this get use the hex, base64 etc. "codecs" back? If yes, great!

> Fine, so we need new methods for PyUnicode and PyString objects
> which allow encoding and decoding using the same type (and enforce
> the return types).
> 
> Any suggestions ?
> 
> How about these:
> 
> str.str_encode() -> str
> str.str_decode() -> str
> 
> bytes.bytes_encode() -> bytes
> bytes.bytes_decode() -> bytes

Cool, a naming contest :)

What about transform/untransform?

Georg



More information about the Python-3000 mailing list