Re: [Gretl-devel] python foreign problems

On Sat, 2 Mar 2013, Sven Schreiber wrote: > some more issues (with solutions...) on the foreign=python front here. > > 1) In gretltmp.py, "execfile": I just found out that this was scrapped > in Python 3. There is an official replacement (in Python's 2to3 > conversion tool), but here I think it's simpler to just replace it with: > <python> > from gretl_io import gretl_dotdir, gretl_loadmat, gretl_export > </python> > This should work on all Python versions, but it assumes that gretl_io.py > will always be in the same directory as gretltmp.py, but AFAIU that's > the case by construction, no? Yes, should be.

> 2) In gretl_io.py, first I think the gretl_export() function is a little > broken: The target file is opened in text mode but apparently savetxt > writes bytes, which it cannot do on text-mode opened files. So the > export doesn't take place. (Or did it for you?) It did work for me, but actually I now see that it may well invoke undefined behavior: we've got a write handle to fname open and then we call savetxt which presumably opens the file for writing itself. Not very nice. A solution would be to > tell savetxt to also write the header, and all the other lines would be > unnecessary: > <python> > # f = open(fname, 'wb') > # f.write(repr(r) + '\t' + repr(c) + '\n') > savetxt(fname, M, fmt='%.18e', delimiter=' ', > header=repr(r)+'\t'+repr(c), comments='') > # f.close() > # return > </python> > The drawback is that this is a new feature in Numpy 1.7 which was just > released last month. OTOH it's a new gretl feature as well, so maybe > it's ok to have demanding version requirements. Presumably another solution would be to bypass savetxt and just do a low-level write-out of the values in the matrix. I'll experiment.