Jeremy Hylton wrote: > 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. In my reply to Guido's post I mentioned that it would be reasonable to limit the number of types to 2 (basically types.StringTypes and subclasses). We could then add two new helpers codecs.encode() and .decode() to do more general codec work without this type restriction. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4