[Python-Dev] New lines, carriage returns, and Windows

Nick Maclaren nmm1 at cus.cam.ac.uk
Sun Sep 30 11:49:56 CEST 2007


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
> I don't see how this is different from Unix/C "\n" being
> an atomic newline character.

Have you used systems with the I/O models I referred to (or ones
with newlines being out-of-bound data)?

> If you're saying that BCPL is better because it defines
> standard semantics for more control characters than just
> "\n", that may be true, but C is doing about the best it
> can with "\n" as far as I can see, given all the crazy
> things that different OSes want to do with line endings.

I am afraid that you are wrong - see my other posting for how
to do it better.  Look, I have implemented both of those two models
on systems that are FAR more different than most people can imagine.
Both work, and neither causes confusion.  The C/Unix/Python one does.

> In any case, the problem which started all this isn't
> really an I/O problem at all, it's a mismatch between
> the world of Python strings which use "\n" and .NET
> library code expecting strings which use "\r\n".

That's an I/O problem :-)

> The correct thing to do with that is to translate whenever
> a string crosses a boundary between Python code and
> .NET code. This is something that ought to be done
> automatically by the Python/.NET interfacing machinery,
> maybe by having a different type for .NET strings.

Agreed.  But the REASON it causes trouble is the inconsistency
in the basic C/Unix/Python text I/O model.  Let's consider just
\f, \r and \n, and a few questions:

    Exactly what does a free-standing \f mean?

    Does \n\f\n mean starting at the top of a page or one line down?

    How do \r and \f interact with line-buffering?  Think about
MacOS here.

I could go on, but those are enough to indicate that the problem
is insoluble.  The answer "Undefined but not even explicitly
discouraged" is a recipe for confusion.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


More information about the Python-Dev mailing list