Message210050
| Author |
ncoghlan |
| Recipients |
Arfrever, elixir, ishimoto, jwilk, loewis, methane, mrabarnett, ncoghlan, nikratio, pitrou, rurpy2, serhiy.storchaka, vstinner |
| Date |
2014年02月02日.23:18:41 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CADiSq7d8npHjKQjz2+w9q7otinAhcOmQfyfCiCQMHFvqmNF_Ng@mail.gmail.com> |
| In-reply-to |
<1391377888.49.0.123388145316.issue15216@psf.upfronthosting.co.za> |
| Content |
It's a blunt instrument to be sure, but a necessary one, I think -
otherwise we end with a scattering of API specific solutions rather than a
single consistent approach.
Here's a thought, though: what if we went with Serhiy's "reconfigure"
idea, limited that to seekable streams (resetting then back to the start of
the file) and then also had a "force_reconfigure" that bypassed the safety
checks?
The main problem I see with that idea is that some changes (binary vs text,
universal newlines or not, buffered or not) would potentially require
adding or removing a class from the stream's IO stack, thus rendering it
difficult to handle as an in-place operation.
However the "seekable streams only by default, flag or separate method to
force an encoding change for a non-seekable stream" approach would be
applicable even for the basic "set_encoding" API.
I'm beginning to think that this is all complicated enough that it should
be written up in a PEP for 3.5 before we actually commit anything (even if
what we end up committing is just set_encoding with a "force=False" keyword
only parameter). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年02月02日 23:18:41 | ncoghlan | set | recipients:
+ ncoghlan, loewis, ishimoto, pitrou, vstinner, jwilk, mrabarnett, Arfrever, methane, nikratio, rurpy2, serhiy.storchaka, elixir |
| 2014年02月02日 23:18:41 | ncoghlan | link | issue15216 messages |
| 2014年02月02日 23:18:41 | ncoghlan | create |
|