[EMAIL PROTECTED] (Marco Colombo) writes:
> 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."
>
> This is the language _reference_ manual, btw. I'm very surprised to hear
> python on windows is so broken.
I believe this is wrong in two ways - first, it hasn't been updated
to cater for the recent "Universal Newline" support, and second, it
applies only to Python source code files (embedded code using the C
APIs should pass code using C newline conventions, ie \n characters,
as we have confirmed). I've submitted a Python bug report (SF ref
1167922) against the documentation.
I've suggested updated wording for this section as follows:
"""
A physical line is a sequence of characters terminated by an end-of-line
sequence. In source files, any of the standard platform line
termination sequences can be used - the \UNIX form using \ASCII{} LF
(linefeed), the Windows form using the \ASCII{} sequence CR LF (return
followed by linefeed), or the Macintosh form using the \ASCII{} CR
(return) character. All of these forms can be used equally, regardless
of platform.
When embedding Python, source code strings should be passed to Python
APIs using the standard C conventions for newline characters (the
\code{\e n} character, representing \ASCII{} LF, is the line
terminator).
"""
Is that clearer?
Paul.
--
Once the game is over, the King and the pawn go back in the same box. --
Italian Proverb
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
