Alexey Luchko <soulne...@gmail.com> added the comment:

1. On quopri.

It is counter-intuitive despite the clear statement in the doc-string. 
Quoted-printable is used mostly for text encoding. (It would be quite awkward 
and inefficient to use it for binary data.)

My case: I have a text and I mean to get a text. Why on earth StringIO is not 
suitable for this goal... It is just crazy!


2. On duck typing and StringIO.

It should make life easy, not crazy. But with great power... You know.

Taking a wider look than just quopri, the case shows a problem – writing text 
to StringIO produces a type error stating *string argument expected*.
That is crazy and as counter-duck-typing as type checking.
And even more ... crazy in case of 7bit ascii!

There could be a solution on StringIO side, like an encoding it should expect 
on input if it gets binary data. At least 7bit ascii would be totally ok for 
default it this case.
Then it either would have worked or would have produced a clear text encoding 
related error that would be *meaningful* and *instructive*.


3. On protocol.

A protocol: write_bytes() and write_string() methods that would have been 
raising type error in case of text_file.write_bytes() or 
binary_file.write_string().
Then one having bytes-*like* object (like quopri.decode) would call 
write_bytes() and StringIO would raise smth like 'StringIO used for binary 
output, consider BytesIO' or 'Text file requires strings, not bytes' that would 
be meaningful as well.
Other one having string-*like* object would call knowingly write_string() with 
a corresponding error from BytesIO or binary file.

*There is nothing of checking in the protocol, but clear intention statement.*

Disclaimer:
  It is just an example and an opinion. There is no reason for holy war.
  I don't pretend it would be any better...

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32268>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to