[Python-3000] Lines breaking

[Stephen J. Turnbull]

<ca471dc20705281544i3be797f7ldab472dac3e1f543 at mail.gmail.com>
	<acd65fa20705281649m7a7a871bw8d690456202f7b83 at mail.gmail.com>
	<465B814D.2060101 at canterbury.ac.nz>
	<465BB994.9050309 at v.loewis.de>
	<465CD016.7050002 at canterbury.ac.nz>
	<87ps4j0zi6.fsf at uwakimon.sk.tsukuba.ac.jp>
	<465E37C3.9070407 at canterbury.ac.nz>
	<8764691mpq.fsf at uwakimon.sk.tsukuba.ac.jp>
	<465F59E9.4030702 at canterbury.ac.nz>
	<87y7j4z7at.fsf at uwakimon.sk.tsukuba.ac.jp>
	<07Jun1.111434pdt."57996"@synergy1.parc.xerox.com>
X-Mailer: VM 7.17 under 21.5  (beta27) "fiddleheads" (+CVS-20070324) XEmacs Lucid
Date: Sat, 02 Jun 2007 13:03:10 +0900
Message-ID: <87tztrypdt.fsf at uwakimon.sk.tsukuba.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Bill Janssen writes:

 > > The *only* thing that adoption of the Unicode recommendation for line
 > > breaking changes is that "\x0c\n" is now two empty lines with well-
 > > defined semantics instead of some number of lines with you-won't-know-
 > > until-you-ask-the-implementation semantics.
 > 
 > Well, that's just the way text is.

If it were *text*, it wouldn't matter, you say yourself.  People would
be able to live with an empty first line.  The issue arises because
you've defined a *formal data format* embedded in text which conflicts
with long-established standards for text.  Now we have an attempt to
define a universal standard for text, which conflicts with your
practice.

 > > You just object to adopting a standard, period, because it might force
 > > you to change your practices.  That's reasonable, changing working
 > > software is expensive.  But interoperability is an important goal too.
 > 
 > Where, specifically, are the breakdowns in interoperability
 > manifesting themselves?

That's not the point; this is like the logical operations on decimal
thing.  Adopting a standard in full is reassuring to potential users,
who won't complain, they just go away.

 > I'm sort of amazed at the turn of this argument.  Greg is arguing that
 > it might be arbitrarily expensive to make this change,

Which I've acknowledged.  But we have no data at all.  We're talking
about Python 3000, and we know that many programs will require porting
effort anyway.  How expensive is it?  "Arbitrarily" is FUD.

 > But Stephen is arguing that we need to do it anyway to conform to
 > the dictates of some post-facto standards committee (yes, I know, I
 > usually *like* that argument :-).

And you should.

We only *need* to do it if we want to claim Unicode conformance in
this area.  I think that is desirable; readline functionality is very
basic to a text-processing language.

 > How about a subtype of File which supports this behavior?

We're talking about Python 3000, right?  If we're going to claim
conformance, it should be default.  If it's not going to be default,
there's no need to talk about it until somebody writes the module and
submits it for inclusion in the stdlib.