Guido van Rossum wrote:
>>M.-A. Lemburg wrote:
>>
>>>Now that more and more codecs become available and the scope
>>>of those codecs goes far beyond only encoding from Unicode to
>>>strings and back, I am tempted to open up that restriction,
>>>thereby opening up u.encode() for applications that wish to
>>>use other codecs that return e.g. Unicode objects as well.
>>>[...]
>>>Note that codecs are not restricted in what they can return
>>>for their .encode() or .decode() method, so any object
>>>type is acceptable, including subclasses of str or
>>>unicode, buffers, mmapped files, etc.
>>
>>+1. I find it surprising that the restriction exists. I would have
>>thought u.encode('foo') would pretty transparently wrap the foo
>>codec's .encode().
>>
>>This is also a good reminder that type checking of the result of
>>codec or unicode .encode() calls is prudent, anytime.
>
> May I make one tiny objection? I don't know if it's enough to stop
> this (I value it at -0.5 at most), but this will make reasoning about
> types harder. Given that approaches like StarKiller and IronPython
> are likely the best way to get near-C speed for Python, I'd like the
> standard library at least to make life eacy for their approach.
>
> 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'.
Ok, how about a compromise: .encode() and .decode() of string
and unicode objects may return string or unicode objects only
(limiting the set of types to two base types).
I think those would cover 90% of all cases. For the remaining
cases we could add codecs.encode() and codecs.decode()
which then do allow arbitrary return types.
> (I've never liked functions whose return type depends on the value of
> an argument -- I guess my intuition has always anticipated type
> inferencing. :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 17 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