Message376684
| Author |
eryksun |
| Recipients |
Carl Osterwisch, Gabi.Davar, John Florian, chary314, dabrahams, davide.rizzo, dlenski, eric.araujo, eric.smith, eryksun, ethan smith, jaraco, jwilk, martin.panter, ncoghlan, njs, paul.moore, piotr.dobrogost, pitrou, r.david.murray, sbt, steve.dower, tim.golden, zach.ware |
| Date |
2020年09月10日.13:22:00 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1599744120.2.0.661501152484.issue14243@roundup.psfhosted.org> |
| In-reply-to |
| Content |
> we'd have to reimplement the UCRT function using the system API.
Could the implementation drop support for os.O_TEXT? I think Python 3 should have removed both os.O_TEXT and os.O_BINARY. 3.x has no need for the C runtime's ANSI text mode, with its Ctrl+Z behavior inherited from MS-DOS. I'd prefer that os.open always used _O_BINARY and raised a ValueError if passed any of the C runtime's text modes, including _O_TEXT, _O_WTEXT, _O_U16TEXT, and _O_U8TEXT.
If _O_TEXT is supported, then we have to copy the C runtime's behavior, which truncates a Ctrl+Z from the end of the file if it's opened with read-write access. If Unicode text modes are supported, then we have to read the BOM, which can involve opening the file twice if the caller doesn't request read access. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2020年09月10日 13:22:00 | eryksun | set | recipients:
+ eryksun, paul.moore, jaraco, ncoghlan, pitrou, eric.smith, tim.golden, jwilk, eric.araujo, r.david.murray, njs, dabrahams, davide.rizzo, sbt, Gabi.Davar, martin.panter, piotr.dobrogost, zach.ware, dlenski, steve.dower, Carl Osterwisch, ethan smith, John Florian, chary314 |
| 2020年09月10日 13:22:00 | eryksun | set | messageid: <1599744120.2.0.661501152484.issue14243@roundup.psfhosted.org> |
| 2020年09月10日 13:22:00 | eryksun | link | issue14243 messages |
| 2020年09月10日 13:22:00 | eryksun | create |
|