Michael Fuhr wrote:
> On Tue, Jan 18, 2005 at 07:34:59PM -0800, Adrian Klaver wrote:
>
>
>>Actually universal newline support seems to be covered by the following PEP
>>and is present in the version of Python(2.3) I am running.
>>http://www.python.org/peps/pep-0278.txt
>
>
> I see the following in the PEP:
>
> There is no support for universal newlines in strings passed to
> eval() or exec. It is envisioned that such strings always have the
> standard \n line feed, if the strings come from a file that file can
> be read with universal newlines.
>
> Does the above mean that the PyRun_*() family doesn't have universal
> newline support? Or at least that some members of the family don't?
> That would explain why the simple C program I tested failed.
>
> http://archives.postgresql.org/pgsql-general/2005-01/msg00876.php
>
>
>>I would tend to agree with Hong Yuan that the problem exists in plpythonu's
>>handling of newlines.
>
>
> If Python's behavior is intentional then the newline burden would
> seem to be on the user or on plpythonu. I think Tom's point is
> that that's just silly....
Changing this behavior in Python would break backwards compatibility. In
particular, the exec() function accepts strings that have already been
unescaped:
>>> exec('print """\n\r\n\r\n"""')
In the above example, the exec function is being passed a string
containing carridge returns and line feeds - not '\n' and '\r' character
sequences.
It is too late for the Python 2.3 series anyway - 2.3.5 is being
released Jan 26th and there won't be a 2.3.6. If it was championed and
it decided that the above example is a bug and not a feature and a patch
produced, it could get into 2.4.1 due April and 2.5+
I suspect this means fixing this problem in plpythonu for 8.1.
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
