[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