<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<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: <[EMAIL PROTECTED]>
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.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
