From: | Marco Colombo <pgsql(at)esiway(dot)net> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Paul Moore <pf_moore(at)yahoo(dot)co(dot)uk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: New user: Windows, Postgresql, Python |
Date: | 2005-03-16 15:17:51 |
Message-ID: | Pine.LNX.4.61.0503161601390.20758@Megathlon.ESI |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)ESI(dot)it
From | Date | Subject | |
---|---|---|---|
Next Message | John DeSoi | 2005-03-16 15:19:12 | Re: psql file restore - problem with encoding |
Previous Message | Sean Davis | 2005-03-16 15:09:21 | Re: plPerl subroutine |