Re: [Gretl-users] Python and Gretl
Am 27.01.2013 17:47, schrieb Allin Cottrell:
On Sun, 27 Jan 2013, Sven Schreiber wrote:
> 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.
Sure, but Python doesn't speak arrays without numpy, so it's both
together that form the numerical language. So "python-numpy"? (which is
also the name of the debian package BTW).
>> 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"
Well I don't want to call myself a guru, especially given the few hours
I have spent with Python in recent months/years, but the namespace alias
is optional. So you can always do 'import numpy' and then just use
'numpy.loadtxt' etc. For the few functions that gretl uses for it's
tricks behind the scenes you could also write:
'from numpy import loadtxt, savetxt'
without having to specify any new namespace label, then you just use
'loadtxt' and 'savetxt' directly (which is bad style in bigger contexts,
but here I think it should be ok). It's no problem to do both this
'from' form for gretl's own needs, and then 'import numpy as
<whatever>'
for further use by the user in the foreign block.
> 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.
Great, thanks.
-sven