> 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. > The ASCII standard, at least as codified in ISO 646, agrees with > Unicode, by referring to ECMA-48/ISO-6249 for the definition of the 32 > C0 characters. I suspect that the ANSI standard semantics of FF and > VT haven't changed since ANSI_X3.4-1963. > > 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? I'm sort of amazed at the turn of this argument. Greg is arguing that it might be arbitrarily expensive to make this change, because of the way that text is used to store data by many programs, and because it's been the way it's been for 15 years of Python history. So the cost of "changing working software" could run into billions; we have no way to know. 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 :-). Yesterday at Google Developer's Day, Alex Martelli told me that Python is about pragmatics; I think I know which side the pragmatic comes down on in this case. How about a subtype of File which supports this behavior? Bill _______________________________________________ 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
