Am 28.01.2013 03:17, schrieb Allin Cottrell:
> 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.

The scipy thing is actually also a good reason not to use numpy blindly,
because a user may want to work with stuff which is only in scipy.

Numpy is a hard dependency of scipy, so I don't think this is really an issue. Even if I want to work only with, say, scipy.stats, I'm (almost all the time) going to be using numpy arrays to do so.

>
> 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?

Yes; OTOH gretl could try to catch the resulting import error:

<python>
try:

def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M

except ImportError:
<somehow signal the absence of numpy to gretl>
</python>

Catching the import error would indeed be nice for users.

Perhaps this is off-topic, but what happens with something like time-series or panel data?

>
>> 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.

I agree, or at least I don't see the use case.

FWIW I tend to agree. As I already mentioned, I think it would be great to expose the gretl library code to the Python side of things, for those that prefer to work mainly in Python.

Skipper