[Python-Dev] bytes.from_hex()

[Ron Adam]

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