RetroSearch Browse

Thu Jun 17 21:59:42 EDT 2004 · https://mail.python.org/pipermail/python-dev/2004-June/045445.html

On Thu, 17 Jun 2004 08:43:15 -0700, Guido van Rossum <guido at python.org> wrote:
> 
> The issue is that currently the type inferencer can know that the
> return type of u.encode(s) is 'unicode', assuming u's type is
> 'unicode'.  But with the proposed change, the return type will depend
> on the *value* of s, and I don't know how easy it is for the type
> inferencers to handle that case -- likely, a type inferencer will have
> to give up and say it returns 'object'.

Who cares about the type inference <0.2 wink>.  It's harder for the
reader of the program to understand if encode() returns a different
type.  Would there be some common property that all encode() return
values would share?  Can't think of one myself.

Jeremy

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

Showing content from https://mail.python.org/pipermail/python-dev/2004-June/045445.html below:

[Python-Dev] Allowing u.encode() to return non-strings