RetroSearch Browse

Thu Mar 2 05:01:10 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-March/061982.html

Greg Ewing wrote:
> Ron Adam wrote:
> 
>> While playing around with the example bytes class I noticed code reads 
>> much better when I use methods called tounicode and tostring.
>>
>>     b64ustring = b.tounicode('base64')
>>     b = bytes(b64ustring, 'base64')
> 
> I don't like that, because it creates a dependency
> (conceptually, at least) between the bytes type and
> the unicode type. And why unicode in particular?
> Why should it have a tounicode() method, but not
> a toint() or tofloat() or tolist() etc.?

I don't think it creates a dependency between the types, but it does 
create a stronger relationship between them when a method that returns a 
fixed type is used.

No reason not to other than avoiding having methods that really aren't 
needed. But if it makes sense to have them, sure.  If a codec isn't 
needed probably using a regular constructor should be used instead.

>> I'm not suggesting we start using to-type everywhere, just where it 
>> might make things clearer over decode and encode.
> 
> Another thing is that it only works if the codec
> transforms between two different types. If you
> have a bytes-to-bytes transformation, for example,
> then
> 
>   b2 = b1.tobytes('some-weird-encoding')
> 
> is ambiguous.

Are you asking if it's decoding or encoding?

   bytes to unicode ->  decoding
   unicode to bytes ->  encoding

   bytes to bytes -> ?

Good point, I think this defines part the difficulty.

1. We can specify the operation and not be sure of the resulting type.

   *or*

2. We can specify the type and not always be sure of the operation.

maybe there's a way to specify both so it's unambiguous?

Ron

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

Showing content from https://mail.python.org/pipermail/python-dev/2006-March/061982.html below:

[Python-Dev] bytes.from_hex()