Hi Huidae,
{I took liberty to move discussion to ML}
2016-04-11 15:54 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
That was a copy+paste from the same script, but I think \r\n is safer than
os.linesep just in case v.to.db prints out \r for whatever reason. But I
know that won't happen in non-Windows anyway, so os.linesep should be fine?
hm, you are right, but still I would prefer to use os.linesep over
'\r\n'. The only problem can happen when the user will ship generated
files between Unix and Windows OS.
Any comments from others?
Thanks, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
What about this then? For reading text files, use \r\n. For reading outputs from GRASS modules and writing, use os.linesep.
I think this makes sense because it can handle cross platform files safely and it’s very unlikely to have mixed newlines from modules compiled on the same platform.
Or simply just use \r\n for reading and os.linesep for writing?
–
Sent from my phone
On Apr 11, 2016 10:58 AM, “Martin Landa” <landa.martin@gmail.com> wrote:
Hi Huidae,
{I took liberty to move discussion to ML}
2016-04-11 15:54 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
That was a copy+paste from the same script, but I think \r\n is safer than
os.linesep just in case v.to.db prints out \r for whatever reason. But I
know that won’t happen in non-Windows anyway, so os.linesep should be fine?
hm, you are right, but still I would prefer to use os.linesep over
‘\r\n’. The only problem can happen when the user will ship generated
files between Unix and Windows OS.
Any comments from others?
Thanks, Martin
–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Mon, Apr 11, 2016 at 11:15 AM, Huidae Cho <grass4u@gmail.com> wrote:
What about this then? For reading text files, use \r\n. For reading
outputs from GRASS modules and writing, use os.linesep.
I think this makes sense because it can handle cross platform files safely
and it's very unlikely to have mixed newlines from modules compiled on the
same platform.
Or simply just use \r\n for reading and os.linesep for writing?
It seems to me that one of these is need and simple os.linesep is not
enough. I'm never sure how Python solves this for splitlines() and others.
I was quite struggling with it in the gunittest where sample data and code
usually have \n but on Windows you get \r\n in the created data. Now I'm
usually replacing \r\n everywhere and doing comparisons afterwards but
that's not really applicable for the normal code.
Vaclav
https://trac.osgeo.org/grass/changeset/64662
https://trac.osgeo.org/grass/changeset/64734
https://trac.osgeo.org/grass/changeset/64683
It seems to me that one of these is need and simple os.linesep is not
enough. I'm never sure how Python solves this for splitlines() and others.
str.splitlines() treats any of '\n', '\r' and '\r\n' as a separator,
independent of platform.
The same approach is used if a file is opened with universal newlines
('U' in the mode string).
I was quite struggling with it in the gunittest where sample data and code
usually have \n but on Windows you get \r\n in the created data. Now I'm
usually replacing \r\n everywhere and doing comparisons afterwards but
that's not really applicable for the normal code.
Unless 'b' is added to the mode, on Windows '\n' will be converted to '\r\n' on
output and '\r\n' to '\n' on input.
--
Glynn Clements <glynn@gclements.plus.com>