Re: [Gretl-devel] python foreign problems
Am 27.02.2013 19:03, schrieb Allin Cottrell:
On Wed, 27 Feb 2013, Sven Schreiber wrote:
> First, a prelim question: In the gretl_io.py file that gretl writes out,
> why use this function
> <python>
> def gretl_dotdir():
> dotdir = "C:/Users/svenne/AppData/Roaming/gretl/"
> return dotdir
> </python>
> instead of just a plain string definition 'gretl_dotdir =
"<whatever>"'?
Because we don't like global variables? Actually, I'm not sure
about python and globals, but it seems safer/cleaner, though
admittedly more complex, to have a function.
IIRC the scope of the corresponding string variable should be the module
(here it's the same as the file), this shouldn't really become a global
variable; from another file you would have to access it as
'gretl_io.gretl_dotdir' unless you 'import' it in some other way. I
don't think there is really any advantage of wrapping this one-liner in
a function.
> Secondly, in the 'gretl_export()' function (also in gretl_io.py) the
> seemingly innocuous line
> 'r, c = M.shape'
> might be problematic for vectors (given the next issue this is currently
> hard to test, but I will). The point is that in numpy vectors may be
> represented as 1-dim-arrays; their 'shape' tuple will be '(n,)' and
thus
> have only length one. I guess there are two solutions; either do a check
> like 'len(M.shape)==1', or force M to be a numpy-matrix which is
> guaranteed to be 2-dim like gretl matrices. Let me test and then think
> about it.
Could we just wrap M as numpy.matrix(M) ? (The gretl_export
function depends on numpy anyway, via savetxt.)
Probably we should use 'asmatrix(M)'
(http://docs.scipy.org/doc/numpy/reference/generated/numpy.asmatrix.html),
but yes, this should do it I guess -- I hope there are no side effects
on 'savetxt'.
> Third, a real problem: The gretltmp.py file written by gretl does not
> preserve the indentation from within gretl's foreign block! Since Python
> uses indentation/whitespace as a syntax element, this is completely
> broken. Allin, your example in ch. 39 doesn't have any indented blocks
> it seems, and so you didn't notice.
True, that rather important point (and silly feature of
python!) had totally escaped me, doh. Should now be fixed in
CVS.
It's been a long time since I saw a quarrel about Python's syntax, and I
won't start one here :-) Thanks for fixing.
> And finally, another indentation-related less severe problem: gretl's
> script editor's on-the-fly indentation is a little annoying when writing
> in Python because it does it wrong (understandably). Could this be
> somehow turned off inside foreign blocks?
Yes, I'll work on that.
Thanks again.
-sven