Greg Ewing wrote:
> Ron Adam wrote:
>
>> This would apply to codecs that
>> could return either bytes or strings, or strings or unicode, or bytes or
>> unicode.
>
> I'd need to see some concrete examples of such codecs
> before being convinced that they exist, or that they
> couldn't just as well return a fixed type that you
> then transform to what you want.
I think text some codecs that currently return 'ascii' encoded text
would be candidates. If you use u'abc'.encode('rot13') you get an ascii
string back and not a unicode string. And if you use decode to get back,
you don't get the original unicode back, but an ascii representation of
the original you then need to decode to unicode.
> I suspect that said transformation would involve some
> further encoding or decoding, in which case you really
> have more than one codec.
Yes, I can see that.
So the following are probable better reasons to specify the type.
Codecs are very close to types and they quite often result in a type
change, having the change visible in the code adds to overall
readability. This is probably my main desire for this.
There is another reason for being explicit about types with codecs. If
you store the codecs with a tuple of attributes as the keys, (name,
in_type, out_type), then it makes it possible to look up the codec with
the correct behavior and then just do it.
The alternative is to test the input, try it, then test the output. The
look up doesn't add much overhead, but does adds safety. Codecs don't
seem to be the type of thing where you will want to be able to pass a
wide variety of objects into. So a narrow slot is probably preferable
to a wide one here.
In cases where a codec might be useful in more than one combination of
types, it could have an entry for each valid combination in the lookup
table. The codec lookup also validates the desired operation for nearly
free. Of course, the data will need to be valid as well. ;-)
Cheers,
Ron
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
