getting carried away here...
I took a look at the Python SVN (2.5.4 and 2.6.1) for the gzip lib. I see this:
# guarantee the file is opened in binary mode on platforms
# that care about that sort of thing
if mode and 'b' not in mode:
mode += 'b'
if fileobj is None:
fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
this is going to break for 'U' == you'll get 'rUb' -- who knowes what that means?
now to figure out how to file a ticket...
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...259...
Christopher Barker wrote:
Jeff Whitaker wrote:
Chris: Here's a self-contained example of the problem (data file attached):
yup -- I get the same problem. Interesting, I thought it might be an issue with the 'U' flag creating a difference in byte offset, but that's a unix style file already, so it should make no difference anyway -- weird.
Actually, what's probably happening is that the flags are getting passed in to how python is opening the gzip file itself, in which case, yes, 'U' would, or course, break things.
In the MPL code, is the flag passed on through to either file() or gzip.open() that same way? What I'm getting at is whether it's easy to use 'U' with raw text files and not with gzipped files.
In my grepping of the code (SVN head), I only see gzip.open being called "raw", either with no flags or 'wb', except in mlab.cbook, and I see you (or someone!) already patched that. However, I might suggest:
flag = flag.replace('U','')
instead of:
if flag == 'rU': flag = 'r'
Chris: That's a good idea. Done (r6852).
-Jeff
···
it case someone passes a U in some other way (not that I know of any other valid way...)
Now I wonder if I can find the energy to submit a bug report to Python...
-Chris
--
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory
Jeff et al:
I submitted a bug report about universal newline support in the gzip module. It's been fixed. Much thanks to Skip Montanaro:
http://bugs.python.org/issue5148
I have no idea if this issue exists in the zip module and/or py3k, but it's a start.
Of course, we can't count in it for ages, as we need MPL to work on older versions of Python, but it's a step in the right direction.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...259...