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
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
···
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?
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
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
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
···
On Sun, Jan 25, 2009 at 3:23 PM, C Lewis <chlewis@...2456...> 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.
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.
test_csv2rec.py (350 Bytes)
triangleplot_demo.csv (275 Bytes)
triangleplot_demo2.csv (264 Bytes)
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')
···
On Sun, Jan 25, 2009 at 3:59 PM, C Lewis <chlewis@...2456...> 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.
---------------------------------------------------------------------------
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')]
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
Chris.Barker@...259...
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
PEP 278 – Universal Newline Support | peps.python.org
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
···
On Mon, Jan 26, 2009 at 1:10 PM, Christopher Barker <Chris.Barker@...259...> 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?
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
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
Chris.Barker@...259...
Fair enough -- changed on the trunk in r6845
JDH
···
On Wed, Jan 28, 2009 at 2:11 PM, Christopher Barker <Chris.Barker@...259...> 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.
John Hunter wrote:
···
On Wed, Jan 28, 2009 at 2:11 PM, Christopher Barker > <Chris.Barker@...259...> 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 r6845JDH
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 : 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
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 >> <Chris.Barker@...259...> 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
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
Chris.Barker@...259...
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
Chris.Barker@...259...
here are my test files -- just to save you a minute if you want to try it yourself.
-CHB
test_newlines.txt (54 Bytes)
test_newlines.txt.gz (77 Bytes)
···
--
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:
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
Chris.Barker@...259...
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 : 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
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
etopo20lats.gz (3.63 KB)
···
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 : 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 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
Chris.Barker@...259...