Re: [Gretl-users] Python and Gretl

[Skipper Seabold]

On Mon, Jan 28, 2013 at 2:17 AM, Sven Schreiber <svetosch(a)gmx.net> wrote:

> 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

On Mon, Jan 28, 2013 at 2:17 AM, Sven Schreiber <sveto...@gmx.net> wrote:

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