Re: New user: Windows, Postgresql, Python

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

In response to

Responses

Browse pgsql-general by date

  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