[Jack] > PEP 278 has been quietly sitting there with nothing much happening, > after some initial discussion with two or three people. > > First question: would people please review it, and preferrably also > test it (esp. windows and linux are platforms on which I would like > to see it tested). I skimmed it a few days ago, but didn't find the time to write a response. I think there were a lot of questions before you wrote the PEP, that the PEP doesn't answer yet. I don't even think that it answers all the questions asked in the SF patch tracker. > Second question: what happens next? How is the PEP accepted? I expect that this PEP needs to be revised a number of times before it's ready to be accepted. Some questions to get you started: - What on earth is a source() call? - Why not support setting the delimiter for output files too? - The 't' mode conflicts with the use of this mode on Windows to be an explicit way to invoke the default text translation mode. - Why can't 't' be used together with '+'? Text mode on Windows supports '+' AFAIK. - How does this interact with xreadlines? With "for line in file" ? - Why settle for a compile-time option that's off by default? That's asking for problems; people who turn it on will write code that uses the 't' mode and then find that it's not portable. - You say that 't' mode is used by import. What about parsing source code from a string? What about Unicode strings? - I think I need more clarification of your remark about locks. If the implementation can be abused to create core dumps, I'm not for it. Note that I'm playing devil's advocate here -- I know there are reasonable answers to many of these questions. But the PEP doesn't give them. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4