This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients amaury.forgeotdarc, gvanrossum, ishimoto, lemburg
Date 2008-05-05.22:07:31
SpamBayes Score 0.00010865769
Marked as misclassified No
Message-id <ca471dc20805051507w7f4ae799w4965721019b9f6ab@mail.gmail.com>
In-reply-to <48085FC6.2070008@egenix.com>
Content
On Fri, Apr 18, 2008 at 1:46 AM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
> On 2008-04-18 05:35, atsuo ishimoto wrote:
>  > atsuo ishimoto <ishimoto@users.sourceforge.net> added the comment:
>  >
>  > Is a codec which encode() returns an Unicode allowed in Python3?
>
>  Sure, why not ?

Actually, it is not. In Py3k, x.encode() always requires x to be a str
(i.e. unicode) instance and return a bytes instance. y.decode()
requires y to be a bytes instance and returns a str (i.e. unicode)
instance.

>  I think you have to ask another question: Is repr() allowed to
>  return a string (instead of Unicode) in Py3k ?

In Py3k, "strings" *are* unicode. The str data type is Unicode.

If you're asking about repr() possibly returning a bytes instance,
definitely not.

>  If not, then unicode_repr() will have to check the return value of
>  the codec and convert it back to Unicode as necessary.

What codec?

>  > I started to think codec is not nessesary, but python function is enough.
>
>  That's what we currently have with unicode_repr(), but it doesn't
>  solve the problem.

I'm lost here.

PS. Atsuo's PEP has now been checked in as PEP 3138. Discussion should
start soon on the python-3000 list.
History
Date User Action Args
2008-05-05 22:07:42gvanrossumsetspambayes_score: 0.000108658 -> 0.00010865769
recipients: + gvanrossum, lemburg, ishimoto, amaury.forgeotdarc
2008-05-05 22:07:35gvanrossumlinkissue2630 messages
2008-05-05 22:07:31gvanrossumcreate