The idea is to support calling Python functions in a limited context within CL syntax. E.g.:
--> imhead pyfunc(varname)
The following are some comments by Rick White about how it might be approached:
Here's the code that gets generated when parentheses are present inside
command-line arguments:
--> c = pyraf.cl2py.cl2py(str='imhead plot(version)')
--> c
<pyraf.cl2py.Pycode instance at 0xf16af8>
--> print c.code
from pyraf import iraf
from pyraf.irafpar import makeIrafPar, IrafParList?
from pyraf.irafglobals import *
import math
def string_proc(mode='al', DOLLARnargs=0, taskObj=None):
Vars = IrafParList?('string_proc')
Vars.addParam(makeIrafPar(mode, datatype='string', name='mode', mode='h'))
Vars.addParam(makeIrafPar(DOLLARnargs, datatype='int', name='$nargs',
mode='h'))
iraf.imhead(iraf.plot(taskObj.version))
The last line is the only one that really matters. It actually calls the IRAF
task plot with the IRAF CL variable version as an argument. To be specific,
it assumes that 'version' is the name of a parameter somewhere in the
list of IRAF namespaces to search, including (1) the task, (2) the task's
package, (3) other enclosing packages, and (4) the CL parameters.
This is weird but is almost useful for your case. E.g.:
--> imhead pyfunc(varname)
would get translated to
iraf.imhead(iraf.pyfunc(taskObj.version))
If there were some way to get the local module namespace passed in as taskObj,
this might be hackable to do something like what you want. Or if we modified
the translation mechanism to look in the Python namespace if the parameter
is not known (somehow, not sure what would be involved in that) that would work
too.
It is possible to do some odd things with this parser quirk:
--> imhead dev$*pix*.imh
dev$pix.imh[512,512][short]: m51 B 600s
dev$wpix.imh[512,512][short]: m51 B 600s
dev$ypix.imh[512,512][short]: m51 B 600s
--> clPrint imhead('dev$*pix*.imh',Stdout=1)
['dev$pix.imh[512,512][short]: m51 B 600s', 'dev$wpix.imh[512,512][short]: m51 B 600s', 'dev$ypix.imh[512,512][short]: m51 B 600s']
This actually executes the imhead task, returning a list of strings (using
the Stdout redirection keyword), and then calls clPrint (which is the CL
print task) with that list as the argument.
I don't know why it works this way, nor whether this is a bug or a feature...
Rick
