comments and questions from Rick White, Phil Hodge, Perry Greenfield:
p.15: I honestly can't figure out what the filename parameter does in the
makeIrafPar function. Do you know where it is used?[ph]
It appears to me that this gets passed around to all the IrafPar?
constructors but never gets used for anything. I wonder if it would be
worthwhile to try to get rid of it.[rw]
Seems like a good thing to do, but probably not for 1.1.1,
but right after we release (but the doc should indicate that
this parameter is severely deprecated, i.e., will very soon
be removed)[pg]
p.4: I still think we should enhance the IrafTaskFactory? function so that
the parfile can be passed as a list of strings. Then it would
not be necessary to have a separate .par file, as the parameter
definitions could be included right in the file. I don't
suppose anyone wants to take a crack at that before we release
this document?[rw]
Again, it worries me to make this change this quickly. Perhaps the
document can say that the next version will support doing this
(and give and example of such a definition). By the way, I'm coming
around to the idea that we should start devoting some resources to
making some of these long-standing changes (and some of these
short-standing changes too <wink> ) soon. [pg]
I agree with the philosophy of not making dramatic changes for this
release. It certainly would make me a little nervous to jump in and
make a bunch of changes right before the release.[rw]
For the filename change, I think we can (after the release) change
things so that it is still a keyword parameter in the user-callable
functions but does not get passed on to the various parameter init
methods. We could add a deprecation warning that appears if anyone
actually passes a value in, and could change the pyraf internal calls
to omit it. I think that would be a pretty safe approach.[rw]
