From: Toon V. <Toon.Verstraelen@UGent.be> - 2006-12-20 11:38:42
Attachments:
Toon.Verstraelen.vcf
|
Hi, Is it possible to make multiline labels with mathtext? When I try this: pylab.title(r"$(a+b)^2\\(a-b)^2$") only the first line is rendered. Is there a way to do this properly? thanks, Toon |
From: Darren D. <dd...@co...> - 2006-12-20 12:27:00
|
On Wednesday 20 December 2006 6:38 am, Toon Verstraelen wrote: > Hi, > > Is it possible to make multiline labels with mathtext? When I try this: > > pylab.title(r"$(a+b)^2\\(a-b)^2$") > > only the first line is rendered. Is there a way to do this properly? It looks like this isn't possible right now with regular mathtext. I suggest filing a request on the matplotlib sourceforge site, or even better, submitting a patch. In the meantime, your example works with usetex: True. Darren |
From: Toon V. <Toon.Verstraelen@UGent.be> - 2006-12-20 13:18:40
Attachments:
Toon.Verstraelen.vcf
|
Darren Dale wrote: > On Wednesday 20 December 2006 6:38 am, Toon Verstraelen wrote: >> Hi, >> >> Is it possible to make multiline labels with mathtext? When I try this: >> >> pylab.title(r"$(a+b)^2\\(a-b)^2$") >> >> only the first line is rendered. Is there a way to do this properly? > > It looks like this isn't possible right now with regular mathtext. I suggest > filing a request on the matplotlib sourceforge site, or even better, > submitting a patch. In the meantime, your example works with usetex: True. > > Darren Ok, I will take a look at it. Is the suggested syntax with the double backslash satisfactory? Should the patch be written for mathtext or for mathtext2? greetz, Toon |
From: C L. <ch...@na...> - 2009-01-25 21:23:22
|
In matplotlib.mlab.csv2rec in 0.91.2 (*) headers = reader.next() fails with "Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode?" Which sounds like a good idea, but I can't figure out how to specify that in/with/before calling csv2rec. (In the short term, fixing the new-lines works, but I'd like to share the code.) (*) ... upgrading even to the current Enthought dist stops my main project from running, and I was hoping not to have to work this out before my next deadline. Oy. Chloe Lewis Division of Ecosystem Sciences, ESPM University of California, Berkeley |
From: John H. <jd...@gm...> - 2009-01-25 21:27:45
|
On Sun, Jan 25, 2009 at 3:23 PM, C Lewis <ch...@na...> wrote: > In matplotlib.mlab.csv2rec in 0.91.2 (*) > > headers = reader.next() > > fails with "Error: new-line character seen in unquoted field - do you > need to open the file in universal-newline mode?" Which sounds like a > good idea, but I can't figure out how to specify that in/with/before > calling csv2rec. > Perhaps you can post the file so we can take a look? FYI, you can pass a file handle in to csv2rec, so if you need to open the file in some special mode, do so and pass csv2rec the file handle rather than file name. JDH |
From: C L. <ch...@na...> - 2009-01-25 22:15:18
|
Tiny case appended. On my system (OS X), csv2rec() of the first file is fine, csv2rec() of the second fails with the mentioned error; they only differ in newline characters. Inconveniently, the one that fails seems to be Excel's default export. |
From: John H. <jd...@gm...> - 2009-01-25 22:56:13
|
On Sun, Jan 25, 2009 at 3:59 PM, C Lewis <ch...@na...> wrote: > Tiny case appended. > > On my system (OS X), csv2rec() of the first file is fine, csv2rec() of the > second fails with the mentioned error; they only differ in newline > characters. Inconveniently, the one that fails seems to be Excel's default > export. OK, I can reproduce the problem and the solution is easy. Open the file in universal mode and pass the file handle to csv2rec:: fh= file('myfile.csv', 'rU') r = csv2rec(fh) fh.close() Here is an example ipython session: In [2]: import matplotlib.mlab In [3]: r = matplotlib.mlab.csv2rec('tr triangleplot_demo2.csv try In [3]: r = matplotlib.mlab.csv2rec('triangleplot_demo2.csv') --------------------------------------------------------------------------- Error Traceback (most recent call last) /Users/jdhunter/Desktop/<ipython console> in <module>() /Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/mlab.pyc in csv2rec(fname, comments, skiprows, checkrows, delimiter, converterd, names, missing, missingd, use_mrecords) 2513 2514 if needheader: -> 2515 for row in reader: 2516 #print 'csv2rec', row 2517 if len(row) and row[0].startswith(comments): Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? In [4]: fh = file('triangleplot_demo2.csv', 'rU') In [5]: r = matplotlib.mlab.csv2rec(fh) In [6]: fh.close() In [7]: print r.dtype [('sand', '<i4'), ('silt', '<i4'), ('clay', '<i4'), ('om', '<i4'), ('porosity', '<i4'), ('site', '|S3')] |
From: Christopher B. <Chr...@no...> - 2009-01-26 19:10:42
|
John Hunter wrote: > OK, I can reproduce the problem and the solution is easy. Open the > file in universal mode and pass the file handle to csv2rec:: Shouldn't csv2rec open files in Universal mode by default anyway? -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 Chr...@no... |
From: John H. <jd...@gm...> - 2009-01-26 19:58:59
|
On Mon, Jan 26, 2009 at 1:10 PM, Christopher Barker <Chr...@no...> wrote: > John Hunter wrote: >> OK, I can reproduce the problem and the solution is easy. Open the >> file in universal mode and pass the file handle to csv2rec:: > > Shouldn't csv2rec open files in Universal mode by default anyway? The only down side I can see to this is universal support can be disabled at build time, though it is on by default. At least this is my interpretation of http://www.python.org/dev/peps/pep-0278/ It's a pretty rare bug (in my experience and I work on linux, unix and os x and freqeuently with excel files) with an easy workaround (pass in your own file handle) so I am not sure we need a fix here. JDH |
From: Christopher B. <Chr...@no...> - 2009-01-28 20:11:31
|
John Hunter wrote: > On Mon, Jan 26, 2009 at 1:10 PM, Christopher Barker >> Shouldn't csv2rec open files in Universal mode by default anyway? > > The only down side I can see to this is universal support can be > disabled at build time, though it is on by default. At least this is > my interpretation of > > http://www.python.org/dev/peps/pep-0278/ well, that was 7 years ago (wow!), I don't know if anyone turns it off now, but in any case, so what? it'll act like it does now ( open() ignores flags it doesn't understand -- at least it did ) > It's a pretty rare bug (in my experience and I work on linux, unix and > os x and freqeuently with excel files) with an easy workaround (pass > in your own file handle) so I am not sure we need a fix here. But why the heck not? and according to the OP, Excel does create such files. Personally, I try to ALWAYS use 'U' when opening text files -- it can save headaches, and I see no downside. It really should be the default -- it's not, because the default was always text, but that was the same as binary on *nix -- so there is a lot of *nix code out there opening binary files without the 'b' flag. So we couldn't change the default back in 2002, it would have broken a LOT of code. -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 Chr...@no... |
From: John H. <jd...@gm...> - 2009-01-28 20:39:51
|
On Wed, Jan 28, 2009 at 2:11 PM, Christopher Barker <Chr...@no...> wrote: > But why the heck not? and according to the OP, Excel does create such files. > > Personally, I try to ALWAYS use 'U' when opening text files -- it can > save headaches, and I see no downside. It really should be the default > -- it's not, because the default was always text, but that was the same > as binary on *nix -- so there is a lot of *nix code out there opening > binary files without the 'b' flag. So we couldn't change the default > back in 2002, it would have broken a LOT of code. Fair enough -- changed on the trunk in r6845 JDH |
From: Jeff W. <js...@fa...> - 2009-01-29 16:18:38
|
John Hunter wrote: > On Wed, Jan 28, 2009 at 2:11 PM, Christopher Barker > <Chr...@no...> wrote: > > >> But why the heck not? and according to the OP, Excel does create such files. >> >> Personally, I try to ALWAYS use 'U' when opening text files -- it can >> save headaches, and I see no downside. It really should be the default >> -- it's not, because the default was always text, but that was the same >> as binary on *nix -- so there is a lot of *nix code out there opening >> binary files without the 'b' flag. So we couldn't change the default >> back in 2002, it would have broken a LOT of code. >> > > Fair enough -- changed on the trunk in r6845 > > JDH > > John: 'rU' apparently doesn't work for gzipped text files (at least in python 2.5.2). I had to change the default in back to 'r' when using gzip.open (r6846 in trunk). -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: C L. <ch...@na...> - 2009-01-29 16:47:50
|
To put in an argument each way -- I now recognize that the PEP one gets when looking up "universal newline python" has the necessary info. I saw but did not recognize over the weekend. So one argument is that there's no good reason to risk breaking old defaults, mostly users will be able to solve it themselves. ...*but*, on the other hand: I've checked that more than one Office 2008 install writes files csv2rec can't open without the 'U' flag, and I'm trying to persuade various colleagues that they can move from Excel calculations to Python gradually, and they aren't going to expect line-ending problems. So I guess I see a backwards compatibility problem balanced against a forward evangelizing problem. &C On Jan 29, 2009, at 8:18 AM, Jeff Whitaker wrote: > John Hunter wrote: >> On Wed, Jan 28, 2009 at 2:11 PM, Christopher Barker >> <Chr...@no...> wrote: >> >> >>> But why the heck not? and according to the OP, Excel does create >>> such files. >>> >>> Personally, I try to ALWAYS use 'U' when opening text files -- it >>> can >>> save headaches, and I see no downside. It really should be the >>> default >>> -- it's not, because the default was always text, but that was the >>> same >>> as binary on *nix -- so there is a lot of *nix code out there >>> opening >>> binary files without the 'b' flag. So we couldn't change the default >>> back in 2002, it would have broken a LOT of code. >>> >> >> Fair enough -- changed on the trunk in r6845 >> |
From: Christopher B. <Chr...@no...> - 2009-01-29 18:00:54
|
Jeff Whitaker wrote: > John: 'rU' apparently doesn't work for gzipped text files (at least in > python 2.5.2). I had to change the default in back to 'r' when using > gzip.open (r6846 in trunk). darn -- sounds like a bug/missing feature in the gzip module. Strange , though, unknown flags seem to be ignored by file(), and gzip.open seems to ignore the 'U' too, in my tests (see below). I think having the 'U' ignored is less than optimal, but doesn't make anything worse than it is. What problems did you have? tests (on an OS-X system - native unix newlines): (python 2.5.2) >>> file('test_newlines.txt', 'rb').read() 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' >>> file('test_newlines.txt', 'r').read() 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' >>> file('test_newlines.txt', 'U').read() 'line 1: unix \nline 2: dos \nline 3: mac \nline 4: unix \n' # so file() does the right thing >>> gzip.open('test_newlines.txt.gz', 'rb').read() 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' >>> gzip.open('test_newlines.txt.gz', 'r').read() 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' >>> gzip.open('test_newlines.txt.gz', 'rU').read() 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' # gzip.open() appears to ignore the 'U' flag -- too bad! should we post a bug report/feature request to Python? -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 Chr...@no... |
From: Christopher B. <Chr...@no...> - 2009-01-29 18:02:50
|
C Lewis wrote: > So one argument is that there's > no good reason to risk breaking old defaults, As far as I can see, this won't break any code, though -- Universal newlines won't change anything with native newlines anyway. except maybe with the gzip module... -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 Chr...@no... |
From: Christopher B. <Chr...@no...> - 2009-01-29 18:09:54
Attachments:
test_newlines.txt
test_newlines.txt.gz
|
here are my test files -- just to save you a minute if you want to try it yourself. -CHB -- 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 Chr...@no... |
From: Christopher B. <Chr...@no...> - 2009-01-29 18:21:15
|
Christopher Barker wrote: > here are my test files -- just to save you a minute if you want to try > it yourself. oops -- the email process "fixed" the mixed newlines in test_newlines.txt! At least with my client. It's probably work if you unpack the gz though. -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 Chr...@no... |
From: Jeff W. <js...@fa...> - 2009-01-29 18:38:46
|
Christopher Barker wrote: > Jeff Whitaker wrote: > >> John: 'rU' apparently doesn't work for gzipped text files (at least >> in python 2.5.2). I had to change the default in back to 'r' when >> using gzip.open (r6846 in trunk). > > darn -- sounds like a bug/missing feature in the gzip module. Strange > , though, unknown flags seem to be ignored by file(), and gzip.open > seems to ignore the 'U' too, in my tests (see below). > > I think having the 'U' ignored is less than optimal, but doesn't make > anything worse than it is. What problems did you have? Chris: If you have basemap, try running the simpletest.py example with matplotlib svn r6845. When the filehandle is obtained using 'rU', it's reading garbage from the gzipped file. Using 'r', it's fine. -Jeff > > tests (on an OS-X system - native unix newlines): > (python 2.5.2) > > >>> file('test_newlines.txt', 'rb').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> file('test_newlines.txt', 'r').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> file('test_newlines.txt', 'U').read() > 'line 1: unix \nline 2: dos \nline 3: mac \nline 4: unix \n' > > # so file() does the right thing > > >>> gzip.open('test_newlines.txt.gz', 'rb').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> gzip.open('test_newlines.txt.gz', 'r').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> gzip.open('test_newlines.txt.gz', 'rU').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > > > # gzip.open() appears to ignore the 'U' flag -- too bad! > > should we post a bug report/feature request to Python? > > -Chris > > > > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Jeff W. <js...@fa...> - 2009-01-29 19:01:54
Attachments:
etopo20lats.gz
|
Christopher Barker wrote: > Jeff Whitaker wrote: > >> John: 'rU' apparently doesn't work for gzipped text files (at least >> in python 2.5.2). I had to change the default in back to 'r' when >> using gzip.open (r6846 in trunk). > > darn -- sounds like a bug/missing feature in the gzip module. Strange > , though, unknown flags seem to be ignored by file(), and gzip.open > seems to ignore the 'U' too, in my tests (see below). > > I think having the 'U' ignored is less than optimal, but doesn't make > anything worse than it is. What problems did you have? Chris: Here's a self-contained example of the problem (data file attached): >> import gzip >> f = gzip.open('etopo20lats.gz','rU') >> print f.readline() Traceback (most recent call last): File "testread.py", line 3, in <module> print f.readline() File "/sw/lib/python2.5/gzip.py", line 399, in readline c = self.read(readsize) File "/sw/lib/python2.5/gzip.py", line 227, in read self._read(readsize) File "/sw/lib/python2.5/gzip.py", line 279, in _read uncompress = self.decompress.decompress(buf) zlib.error: Error -3 while decompressing: invalid distance too far back >> import gzip >> f = gzip.open('etopo20lats.gz','r') >> print f.readline() '-8.983333330000000672e+01' -Jeff > > tests (on an OS-X system - native unix newlines): > (python 2.5.2) > > >>> file('test_newlines.txt', 'rb').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> file('test_newlines.txt', 'r').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> file('test_newlines.txt', 'U').read() > 'line 1: unix \nline 2: dos \nline 3: mac \nline 4: unix \n' > > # so file() does the right thing > > >>> gzip.open('test_newlines.txt.gz', 'rb').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> gzip.open('test_newlines.txt.gz', 'r').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > >>> gzip.open('test_newlines.txt.gz', 'rU').read() > 'line 1: unix \nline 2: dos \r\nline 3: mac \rline 4: unix \n' > > > # gzip.open() appears to ignore the 'U' flag -- too bad! > > should we post a bug report/feature request to Python? > > -Chris > > > > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Christopher B. <Chr...@no...> - 2009-01-29 19:48:55
|
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' 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 -- 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 Chr...@no... |
From: Christopher B. <Chr...@no...> - 2009-01-29 19:59:15
|
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 Chr...@no... |
From: Jeff W. <js...@fa...> - 2009-01-29 19:59:48
|
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 : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Christopher B. <Chr...@no...> - 2009-02-05 17:05:44
|
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 Chr...@no... |