[Python-Dev] Please review PEP 278 - Universal newline support

[Guido van Rossum]

[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/)