On Mon, 28 Jan 2013, Pietro Battiston wrote:
Allin, thanks a lot, that's great news.
Il giorno dom, 27/01/2013 alle 18.37 +0100, Sven Schreiber ha scritto:
> 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).
I personally do not agree. The language you will write is simply python,
which, for an implementational detail, uses numpy. I don't think the
user is even necessarily assumed to know this is happening, until she
just reads the docs. Unless there really are any reason why we should
want an additional python "flavour" supported, I think the simplest
alternative, "language=python", is the best.
I'm with you on that, Pietro.
The user can, moreover, do "import numpy" again, or even
"import numpy
as whatever", as suggested, without any damage.
If we really want to be very picky (and in my opinion we don't really
need to), probably the cleanest solution would be to move the "import
numpy as np" line _inside_ each function, so that the "np" name is not
used outside them. This is not exactly nice Python code, but I can't
think of a better solution.
Here's what's in current CVS, following Sven's recent suggestions:
1) In the convenience python functions gretl_loadmat() and
gretl_export() -- for shuttling matrices between gretl and python --
we do this sort of thing:
<python>
def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M
</python>
That is, we import locally the functionality we need from numpy.
2) We leave it up to the user to import from numpy and/or scipy,
with the user's preferred namespace, for more general usage.
Point 1) means that gretl's python support depends on the user
having numpy installed, but I suppose that really goes without
saying: how could you do anything useful in terms of gretl/python
interaction without numpy?
While I'm at it: I guess that now most of the work needed to also
have a
python console running in gretl is done? Let me point out that if that
was the case, it would be great to be able to choose _which_ console to
use (for instance "ipython" instead than simple "python").
Hmm. We currently have the ability to edit/run python scripts in the
gretl gui (with appropriate syntax highlighting) in the same sort of
way as we support Ox programs and R or Octave scripts. As for
providing a "console" (by which I understand an interactive
command-line interface), I'm not sure that is gretl's job.
Allin Cottrell