Fix the use of Pset arguments when calling a task in PyRAF CL

[olebole]

This implements the suggestion by @jehturner in #192 to explicitly propagate Pset arguments to the main dictionary.

Closes: #192

[jehturner]

My suggestion was certainly a bit of a hack, as __pardict is accessed through getter- & setter-type interfaces elsewhere, but I hadn't quite figured out what the usage should be. I did wonder whether the p.get().getParObject(tail) in setParList() should return something linked to the axis parameter from the top-level list (as per your #192 (comment)) and whether that's what's broken (which sounds related to the comment in __addPsetParams()).

[jehturner]

I wonder about something like this?

            if tail:
                # is pset parameter - get parameter object from its task
                p = p.get().getParObject(tail)
                try:
                    p = self.getParObject(p.name)
                except KeyError:
                    p = copy.deepcopy(p)
                    self.addParam(p)

Some thoughts:

• While I've only studied the mechanism to a limited extent, the main parameter list seems to be what's used to construct the message sent to the IRAF process.
• It sounds like the pset parameters were originally linked to the main parameters, but were severed at some point when a design problem became apparent (perhaps related to CL script namespaces).
• Any resulting duplication between the main list and the pset appears to be harmless, having already existed for a long time.
• Since this version doesn't re-establish the link, it avoids any resulting problems (whatever they might be).
• I'm not 100% sure whether the equivalent parameter is guaranteed to exist in the main list by the time this code runs, hence the fallback to addParam(). This is probably unnecessary, but at worst is a couple of redundant lines, to be safe, which we can remove if you are confident that the entry should be there (this isn't very well-tested, since I don't have a real-world case).
• This uses the API, rather than editing private attributes in more places than necessary...

[jehturner]

Ideally, we'd have a test for this, of course (I'd need to look at that later if you want me to add one). Sorry, I messed up slightly above (the deepcopy was a last-minute addition); let me just fix that [done].

[olebole]

I think the parameter is guaranteed to exist because it was added during init by self.addParm() which adds the Pset to self.__psets2merge, from which it is later (by __addPsetParams()) added to the main list; however it cannot hurt to increase robustness by adding the try…except clause as you propose.

So, I added a new commit (and set you as the author to both to make clear who gets the merits :-) ). Ofcourse a test would be great so that we can catch a regression if the needs to be changed again. Do you mind to be added as maintainer so that you could modify the PR yourself? Hidden thought is that it is better to have more people with access to the repository to reduce the bus factor 🚌

[jehturner]

Sure, thank you!