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  (Michael Fuhr <mike@fuhr.org>)
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:

Previous
From: Sean Davis
Date:
Subject: Re: plPerl subroutine
Next
From: John DeSoi
Date:
Subject: Re: psql file restore - problem with encoding