RetroSearch Browse

Thu Feb 16 21:00:42 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-February/061163.html

On 2/15/06, Guido van Rossum <guido at python.org> wrote:
>
> >  Actually users trying to figure out Unicode would probably be better
> served
> > if bytes.encode() and text.decode() did not exist.
> [...]
> It would be better if the signature of text.encode() always returned a
> bytes object. But why deny the bytes object a decode() method if text
> objects have an encode() method?

I agree, text.encode() and bytes.decode() are both swell.  It's the other
two that bother me.

I'd say there are two "symmetric" API flavors possible (t and b are
> text and bytes objects, respectively, where text is a string type,
> either str or unicode; enc is an encoding name):
>
> - b.decode(enc) -> t; t.encode(enc) -> b
> - b = bytes(t, enc); t = text(b, enc)
>
> I'm not sure why one flavor would be preferred over the other,
> although having both would probably be a mistake.
>

I prefer constructor flavor; the word "bytes" feels more concrete than
"encode".  But I worry about constructors being too overloaded.

>>> text(b, enc)  # decode
>>> text(mydict)  # repr
>>> text(b)       # uh... decode with default encoding?

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060216/5138b8fa/attachment.htm 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/061163.html below:

PEP 332 revival in coordination with pep 349?]