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

[Chris Barker]

Just van Rossum wrote:
> Proposal for 2.2, outline for a PEP?

Thanks, Just, for getting this rolling.

> 1)
> The Python file object needs to be modified so that in text mode it can
> recognize all major line ending conventions (Unix, Win and Mac).
> 
> Reading data:
>   - recognize \n, \r and \r\n as line ending, present as \n to Python
> Writing data:
>   - convert \n to the platform line endings (this is already the case)
> 
> This modification should be _optional_, because it may break code under unix
> (insert Guido's explanation here), and because it may not support oddball
> systems like OpenVMS.
> 
> It should be _on_ by default under:
> - Windows
> - MacPython Classic
> - MacPython Carbon
> - Unix Python under MacOS X / Darwin
> 
> It should probably be off by default on all other systems (I think a
> compile-time switch is good enough). Maybe if we advertize the potential
> sloppy-unix-code-breakage loud enough we can make the feature mandatory in a
> later release, however I don't see a practical way of issuing warnings for the
> situation.

I agree that is should be possible to turn the proposed off, but I still
think it should be on by default, even on *nix systems (which is mostly
what I use, buy the way), as it would only cause a problem for "sloppy"
code anyway. Would it be possible to have it be turned on/off at
runtime, rather than compile time ? It would be pretty awkward to have a
program need a specific version of the interpreter to run. Even a
command line flag could be awkward enough, then only the main program
could specify the flag, and modules might not be compatible.

Another option is for the new version to have another flag or set of
flags to the open command, which would indicate that the file being
opened is "Unix", "Mac", "DOS", or "Any". this would make it easy to
write text files in a non-native format, as well as read them.

Even if we didn't go that far, we could use the "t" flag (analogous to
"b" for binary), to specify the universal text format, and the default
would still be the current, native format. This would keep the "sloppy"
*nix code from breaking, and still give full functionality to new code.

While we are at it, what would get written is something we need to
consider. If we just have the above proposal, reading a file would work
great, it could be on a server with a different line ending format, and
that would be transparent. Writing, on the other hand is an issue. If a
program is running on a windows box, and writing a file on a *nix
server, what kind of line ending should it write? Would it even know
what the native format is on the server? It seems we would need to be
able to specify the line ending format explicitly for writing.

Just a few thoughts, maybe we'll get a PEP out of this after all!

-Chris







-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------