Re: New user: Windows, Postgresql, Python - Mailing list pgsql-general
From | Marco Colombo |
---|---|
Subject | Re: New user: Windows, Postgresql, Python |
Date | |
Msg-id | Pine.LNX.4.61.0503161601390.20758@Megathlon.ESI Whole thread Raw |
In response to | Re: New user: Windows, Postgresql, Python (Michael Fuhr <mike@fuhr.org>) |
Responses |
Re: New user: Windows, Postgresql, Python
|
List | pgsql-general |
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. _____/ _____/ _/ Colombo@ESI.it
pgsql-general by date: