| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Fuhr <mike(at)fuhr(dot)org> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Marco Colombo <pgsql(at)esiway(dot)net>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: plpython function problem workaround |
| Date: | 2005-03-18 05:35:07 |
| Message-ID: | 3141.1111124107@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> Apparently any CR or LF is considered a line
> ending in an ordinary Python script, with CR and CRLF normalized
> to LF before being passed to the interpreter, so I'm thinking that
> a Python programmer wouldn't expect to be able to embed CRs in a
> string literal and have them remain unchanged. If that's the case,
> then concerns about CR conversions potentially messing up a user's
> strings might be unfounded.
Yeah, it looks like you are right:
http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/peps/pep-0278.txt?rev=1.2
So that part of it can be solved fairly easily. Unfortunately we are
still left with the issue of having to lex Python programs enough to
know how to indent them ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2005-03-18 07:21:33 | Re: plpython function problem workaround |
| Previous Message | Michael Fuhr | 2005-03-18 04:24:52 | Re: plpython function problem workaround |