Re: [Gretl-users] Python and Gretl
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, "(a)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