Does distutils know or care about text file line endings? I ask only because I would like to be able to build pure python distros and have them work properly on multiple platforms. -- Robin Becker
Robin Becker wrote:
Does distutils know or care about text file line endings? I ask only because I would like to be able to build pure python distros and have them work properly on multiple platforms.
Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
In article <3DAC69C3.10800@lemburg.com>, M.-A. Lemburg <mal@lemburg.com> writes
Robin Becker wrote:
Does distutils know or care about text file line endings? I ask only because I would like to be able to build pure python distros and have them work properly on multiple platforms.
Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.)
well it certainly does in python-2.2.2 and there's pep 278 which seems to be concerned as well. Try entering import a, \ b in mac format and then execute on a windows box. I see the following C:\>\tmp\ttt.py File "C:\tmp\ttt.py", line 1 rlextrareportlab,\ ^ SyntaxError: invalid token -- Robin Becker
Robin Becker wrote:
In article <3DAC69C3.10800@lemburg.com>, M.-A. Lemburg <mal@lemburg.com> writes
Robin Becker wrote:
Does distutils know or care about text file line endings? I ask only because I would like to be able to build pure python distros and have them work properly on multiple platforms.
Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.)
well it certainly does in python-2.2.2 and there's pep 278 which seems to be concerned as well.
Try entering
import a, \ b
in mac format and then execute on a windows box. I see the following
C:\>\tmp\ttt.py File "C:\tmp\ttt.py", line 1 rlextrareportlab,\ ^ SyntaxError: invalid token
Interesting. That must be related to Macs only, though, because I move around between Windows and Unix on a regular basis and have so far never had any problem with line ends. FWIW, Python 2.3 doesn't seem to have this problem anymore and I remember that Jack worked on universal newline support some months ago. BTW, the ZIP utility has an option which takes care of text files: Zip 2.3 (November 29th 1999). Usage: zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list] ... -0 store only -l convert LF to CR LF (-ll CR LF to LF) Perhaps that's the way to go ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
In article <3DAC729A.10603@lemburg.com>, M.-A. Lemburg <mal@lemburg.com> writes .....
Interesting. That must be related to Macs only, though, because I move around between Windows and Unix on a regular basis and have so far never had any problem with line ends.
I think you're right, MACS use only \r which won't work properly for unix \n or dos \r\n. I just tried unix format and that seems to work ok on dos, but for 2.1.2 FreeBSD Python the dos and mac versions seem to be wrong although I may be making some obvious mistake. Python 2.1.2 (#1, Feb 22 2002, 15:59:03) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information.
open('/tmp/mac.py','wb').write('import reportlab,\r\\\trlextra\r') open('/tmp/dos.py','wb').write('import reportlab,\r\n\\\trlextra\r\n')
/usr/RL_HOME/users/robin: # python /tmp/mac.py File "/tmp/mac.py", line 1 \ imporlextrartlab, ^ SyntaxError: invalid syntax /usr/RL_HOME/users/robin: # python /tmp/dos.py File "/tmp/dos.py", line 1 import reportlab, ^ SyntaxError: invalid syntax
as for zip last time I looked it wasn't available by default on Solaris 8 or AIX etc etc, it's not even available by default on win32. -- Robin Becker
On Tuesday, Oct 15, 2002, at 21:55 Europe/Amsterdam, M.-A. Lemburg wrote:
well it certainly does in python-2.2.2 and there's pep 278 which seems to be concerned as well. Try entering import a, \ b in mac format and then execute on a windows box. I see the following C:\>\tmp\ttt.py File "C:\tmp\ttt.py", line 1 rlextrareportlab,\ ^ SyntaxError: invalid token
Interesting. That must be related to Macs only, though, because I move around between Windows and Unix on a regular basis and have so far never had any problem with line ends.
If Python 2.2 and later are the only platforms of interest then you can use unix lineendings, and all Pythons will be happy. MacPython 2.2 has a "poor mans universal newlines" feature, where it recognizes unix lineendings (but *not* windows lineendings) on any text file. And 2.3 has universal newline support on all platforms. -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.)
When you make a package on Windows and ship it to Unix it looks really ugly in VI :-) The converse is true when some sysadmin opens a Unix-built python file in Notepad. We just assumed that it would 'do the right thing' for the platform and normalize stuff somewhere. This is more of a gripe about making zip and tar.gz files than about anything else. If it's all 'unpacked' then who is to say what's right? But if you are making a zip or EXE distro, surely known text files or source files should be \r\n, and if a tar.gz then just \n. I presume the answer is that distutils doesn't do this :-) - Andy
Andy Robinson wrote:
Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.)
When you make a package on Windows and ship it to Unix it looks really ugly in VI :-) The converse is true when some sysadmin opens a Unix-built python file in Notepad. We just assumed that it would 'do the right thing' for the platform and normalize stuff somewhere.
This is more of a gripe about making zip and tar.gz files than about anything else. If it's all 'unpacked' then who is to say what's right? But if you are making a zip or EXE distro, surely known text files or source files should be \r\n, and if a tar.gz then just \n.
distutils uses Unix standard internally (e.g. for pathnames), so the "standard line ending" would be \n only...
I presume the answer is that distutils doesn't do this :-)
...nothing a few subclasses wouldn't be able to add, though. Of course, the right solution would be getting a decent text editor ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Andy Robinson wrote:
Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.)
When you make a package on Windows and ship it to Unix it looks really ugly in VI :-) The converse is true when some sysadmin opens a Unix-built python file in Notepad. We just assumed that it would 'do the right thing' for the platform and normalize stuff somewhere. This is more of a gripe about making zip and tar.gz files than about anything else. If it's all 'unpacked' then who is to say what's right? But if you are making a zip or EXE distro, surely known text files or source files should be \r\n, and if a tar.gz then just \n.
distutils uses Unix standard internally (e.g. for pathnames), so the "standard line ending" would be \n only...
I presume the answer is that distutils doesn't do this :-)
...nothing a few subclasses wouldn't be able to add, though.
Of course, the right solution would be getting a decent text editor ;-)
Which would be VIM ;-) But seriously, to avoid this problem whilst packaging PythonCard we build the windows packages using good old 'cmd' and the *nix packages using either Cygwin or Linux (depending on what I've booted into that day). Distutils seems to use the native platform line endings when assembling the package. Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com
Of course, the right solution would be getting a decent text editor ;-)
No, it wouldn't. We have decent editors. But we ship code to people maintaining Unix systems, who should neither know nor care if it is Java or Python or Algol. If they have to edit some config file in VI when logged into a remote server, it's just wrong to ship it full of ^M thingies; someone actually phoned me and asked if it was safe to promote! At the same time I would quite like the freedom to make a package on my Windows machine, or even on a Mac. (BTW, does OS/X have Unix line endings?) I think the right solution is "a few subclasses" and one day some options in distutils to set this if you choose to. Distutils knows which files are source, tar and zip cannot be expected to. Putting it in perspective: we had a quiet day and all decided to learn distutils, so we may ask some pretty dumb things before we grasp its inner beauty, elegance and fundamental rightness ;-) - Andy
Andy Robinson wrote:
Of course, the right solution would be getting a decent text editor ;-)
No, it wouldn't. We have decent editors. But we ship code to people maintaining Unix systems, who should neither know nor care if it is Java or Python or Algol. If they have to edit some config file in VI when logged into a remote server, it's just wrong to ship it full of ^M thingies; someone actually phoned me and asked if it was safe to promote! At the same time I would quite like the freedom to make a package on my Windows machine, or even on a Mac. (BTW, does OS/X have Unix line endings?)
I think the right solution is "a few subclasses" and one day some options in distutils to set this if you choose to. Distutils knows which files are source, tar and zip cannot be expected to.
That's true, but currently distutils isn't messing with line ends in source code at all -- at least not from what I've seen in the source code or in practice. It does use Unix line ends in some generated files, though. One thing you should consider is shipping the software using Unix line ends to both Windows and Macs. All sane editors in those two worlds know how to deal with Unix file ends (no, Notepad is not a sane editor, it's a text widget demonstration :-). Even if you would be able to define the line endings for various different files by means of options, you'd still run into problems, since files created by your applications wouldn't change, so things would only be half backed in the end. Another problem is that of platform dependent text file mode: on some platforms this adds/removes the CR LF, on others just LF, no idea what Macs do... it's just a mess.
Putting it in perspective: we had a quiet day and all decided to learn distutils, so we may ask some pretty dumb things before we grasp its inner beauty, elegance and fundamental rightness ;-)
Oh dear ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (5)
-
Andy Robinson -
Andy Todd -
Jack Jansen -
M.-A. Lemburg -
Robin Becker