On Sun, 27 Jan 2013, Sven Schreiber wrote: > Am 26.01.2013 20:18, schrieb Allin Cottrell: >> On Sat, 26 Jan 2013, Pietro Battiston wrote: >> >>> I love Gretl's "foreign" code blocks capability, and would love even >>> more the possibility of using Python in them, which was at some time >>> suggested as easy to implement. >> >> Yes, quite easy. In fact, so easy that Python support is now >> in gretl CVS and the snapshots for Windows and OS X. Here's a >> trivial example: > > This is wonderful, thank you Allin!
Glad you like it! >> <hansl> >> matrix M = I(5) >> mwrite(M, "@dotdir/pytest.mat") >> foreign language=python > > Not a big issue, but this treats Python as somehow equivalent to Numpy. > I wonder whether this should be made explicit, also given that the > "import numpy" line is hidden. So maybe 'language=numpy' or 'nppython'? I'd be OK with 'language=numpy' if people think that's better, although I'd say the _language_ is python. >> When python is invoked via gretl, one thing that happens >> automatically is: >> >> import numpy as np >> >> This is in part because numpy is needed for the implementation >> of gretl_loadmat and gretl_export, which use np.loadtxt and >> np.savetxt respectively. I'm not a python person, but I >> suspect that some users might not like the "import" statement >> as I have it. Comments welcome. > > There is certainly nothing wrong with this import statement, but it is a > "secret" in some sense, even though it will be in the docs. Maybe > introduce an argument where the abbreviation can be set, as in 'foreign > language=numpy --as="np"'? Giving the user the choice of "as" would be a bit fiddly, since we need the numpy namespace for basic I/O. But maybe a python guru could suggest a way to conditionalize our calls to the numpy functions? If so, I'd suggest the invocation might be language=python --numpy="np" >> Related question: in Python, as in R, Octave and Ox, the >> "dotdir" business (which ensures we have a user-writable and >> gretl-findable location) is hidden from the matrix read/write >> functions, but on the gretl end you have to use @dotdir >> explicitly with mwrite and mread when interfacing with >> "foreign". >> >> Any sale for a pair of gretl functions mexport() and mimport() >> which handle the prepending of dotdir automatically? > > [...] Instead of introducing new functions, maybe it would > be better to modify the existing mwrite() and mread() functions to > prepend @dotdir by default if the string is recognized as a relative > path. (Caveat: The directory lookup stuff is tricky, and I haven't > thought this through. There could be some interference with workdir. Too messy, I think. > Maybe need to introduce another optional argument in the functions.) OK, that's the route I've taken in current CVS. Now mread() has an optional second (scalar) argument, "import"; if that's non-zero we read from @dotdir. And mwrite has an optional third (scalar) argument, "export"; if non-zero we write into @dotdir. Allin
