On Wed, 16 Mar 2005, Michael Fuhr wrote:
On Wed, Mar 16, 2005 at 01:46:23PM +0100, Marco Colombo wrote:
It seems python documentation is plain wrong, or I'm not able to read it at all:
http://docs.python.org/ref/physical.html
"A physical line ends in whatever the current platform's convention is for terminating lines. On Unix, this is the ASCII LF (linefeed) character. On Windows, it is the ASCII sequence CR LF (return followed by linefeed). On Macintosh, it is the ASCII CR (return) character."
Perhaps the Python documentation could use some clarification about when the platform's convention is required and when it isn't.
The "Embedding Python" documentation shows embedded code with lines ending in \n and without saying anything about requiring the platform's convention:
http://docs.python.org/ext/high-level-embedding.html
This is the language _reference_ manual, btw. I'm very surprised to hear python on windows is so broken.
Anyway, that makes life simpler for us. plpython programs are \n separated, no matter what platform the server runs on.
That the behavior makes life simpler is an argument against it being broken (although it would be even less broken if it were more flexible about what line endings it allows).
broken == 'not conforming to the specifications or the documentation'
The fact it helps us is just a side effect.
A detailed response would be getting off-topic for PostgreSQL, but I'll stand by what I said earlier: I would find it bizarre if embedded Python code had to use different line endings on different platforms. That would mean the programmer couldn't simply do this:
PyRun_SimpleString("x = 1\n" "print x\n");
Instead, the programmer would have to do a compile-time or run-time check and build the string in a platform-dependent manner. What problem would the language be solving by requiring that?
This one:
aprogram = "x = 1\nprint x\n";
printf(aprogram);
PyRun_SimpleString(aprogram);See? THIS program requires compile-time or run-time checks. You can't run it on Windows, or Mac: it'll write garbage to the screen (something that looks like garbage, that is).
Make it more general:
aprogram = get_program_from_somewhere();
PyRun_SimpleString(aprogram);
write_program_to_somefile_possibly_stdout(aprogram);What if get_program_from_somewhere() reads user input? On Windows lines will be \r\n separated. Now, should this program make platform checks? Why not simply read a file (or stdin) in text mode, and pass the result to PyRun_SimpleString()? The same applies to output, of course.
Now something strikes me... in his tests, Paul tried my program and
the output looks identical to Linux. Now... I was expecting program1 (the one with just \n) do display badly under Windows.
Am I missing something? Does C runtime support in Windows convert
\n into \r\n automatically in printf()? If so, I'm on the wrong track.
It may do the same with scanf() and other stdio functions.
I must say I wasn't expecting my program to run just fine, with all those \n I used in it. Staring from
printf("> Initialized.\n");Paul can you please tell me which compiler you used under Windows to complile my program and if you used some weird compiling options? TIA.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
