[Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?

[Guido van Rossum]

[me]
> >You might need to be able to specify a specific line ending format,
> >but there should also be a default -- and it should be the default
> >appropriate to the OS.  So, \n on Unix, \r\n on Windows, \r on Mac
> >running in "Mac mode", and \n on MacOS X running in "Unix mode".

[JW Baxter]
> Is it the same in Mac OS X when reading a file from a UFS volume as from an
> HFS(+) volume?

I'm not sure that the volume from which you're *reading* could or
should have any influence on the default delimiter used for *writing*.
The volume you're *writing* to might, if it's easy to determine -- but
personally, I'd be happy with a default set at compile time.

> Only if the underlying libraries make it so.  (Typing in Mac OS X, but I
> don't have any UFS volumes lying around.)
> 
> It's a little scary to contemplate that reading two different files, which
> happen to be on the same disk spindle, will behave differently for the file
> on the HFS+ volume than for the file on the UFS volume.  [There are perhaps
> similar issues for our Linux friends who mount Windows volumes.]

Anyway, disk spindles are the wrong abstraction level to consider
here.  Who cares about what spindle your files are on?

> What ever happened to "move text files to another system using FTP in ASCII
> mode?"  Ah, yes...it probably died of Unicode.

No, obviously it's cross-platform disk sharing.  The first time this
came up was when it became possible to mount Unix volumes on NT boxes
many years ago, and that's when Python's parser (eventually) grew the
habit of silently ignoring a \r just before a \n in a source file.

It's a sign of how backward the Mac world is that the problem only now
pops up for the Mac. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)