pysas UI is unintuitive and unnecessarily cumbersome

[hamogu]

• Why do I have to pass the arguments when I initialize the Wrapper
  object? From a user perspective, it would make more sense to pass them
  when I run a task, so something like this:

  from pysas.wrapper import Wrapper
  evselect = Wapper('evselect')
  evselect.run(my_arguments_here)

• Why do I have to create the Wrapper objects in the first place? There is only a finite (small) number of SAS tasks that exist, so why don't we create watrtter objects for each task on init (or lazily on import) so that I can do:

  from pysas import evselect

• In pysas, I pass in arguments to tasks as strings that look exactly
  like they would on the SAS command line. So, as a Python user, I need to
  construct those argument strings first, often from a dictionary. Then,
  the task internally breaks those up into dictionaries, performs some
  checks on those dictionaries, and then transforms it back into strings.
  Why can't I pass in a dictionary in the first place?

• Most of the classes have only one method ("run"), e.g.
  runtask.Runtask, sastask.MyTask. What's the point of making that a
  class? (see the classic talk https://www.youtube.com/watch?v=o9pEzgHorH0).

Note that all this could be done in a way that's backwards compatible, for example from poses import evselect could be added to the namespace today with our breaking existing code. Those new imports could then also be more Pythonic - accept individual arguments in the usual key=value form instead of the long list of strings.

[rjtanner]

Why do I have to pass the arguments when I initialize the Wrapper object? From a user perspective, it would make more sense to pass them when I run a task.

That can be a possibility for future development. But in practice the creation and running of the wrapper object happen in the same step.

Why do I have to create the Wrapper objects in the first place?

Definitely not my choice. But for backwards compatibility we have to keep it for now. Things may be different in pySAS v. 2.0.

There is only a finite (small) number of SAS tasks that exist

There are over 300. Last year I did look into the possibility of writing something to automatically convert all tasks into their own function or object. Basically I was writing a wrapper for the wrapper. That project got put on hold because I had to focus my efforts elsewhere.

In pysas, I pass in arguments to tasks as strings that look exactly like they would on the SAS command line.... Why can't I pass in a dictionary in the first place?

You can! The inputs can be passed in as a dictionary. Details can be found here (near the end of the document): https://github.com/XMMGOF/pysas/blob/main/documentation/using_pysas.ipynb

But yes, it's a little ridiculous to pass it in as a list, only to have pySAS convert it into a dictionary (and finally into a string). It's even worse when you pass in the inputs as a dictionary, because it first has to convert the dictionary into a list of strings, just so that it can be passed through and then be converted back into a dictionary.

Not my choice of design. But for backwards compatibility we have to keep it for now. Things may be different in pySAS v. 2.0.

Most of the classes have only one method ("run"), e.g. runtask.Runtask, sastask.MyTask. What's the point of making that a
class?

I asked myself the same question when I saw that in the code. I have a long list of "Why did they do that?!?!" that I have collected.

Note that all this could be done in a way that's backwards compatible, for example from poses import evselect could be added to the namespace today with our breaking existing code. Those new imports could then also be more Pythonic - accept individual arguments in the usual key=value form instead of the long list of strings.

The problem is that each SAS task has default input parameters and the default parameters can be different depending on which version of SAS the user is running. Even the available input parameters can be different depending on which version of SAS the user is running. So the inputs for each task would have to be auto-generated when the user configures pySAS for the first time, or auto-generated each time pySAS is imported.

As I mentioned before, I had tried developing something that would do this, but I couldn't do it without significant rewrites to the core pySAS code. Which for various reasons couldn't happen.