python: promote JobInfo class to bindings

[grondo]

As a first step toward #3032, lets at least uplift the JobInfo class into the Python bindings.

Requiring users of the job_list() API to decode some of the low level data in the response seems unkind (e.g. state and result are just integers). By allowing wider use of JobInfo class we can make the interface much more usable.

Perhaps a JobInfo constructor could also be used in place of, or as an enhancement to, the custom JobRecord class discussed in #3136.

[grondo]

Just looking into doing a quick experiment moving the JobInfo class into the flux.job module, however this will start to make job.py pretty long.

I don't have much experience with Python module development, can we easily split job.py into multiple files by making a new directory src/bindings/python/flux/job with an __init__.py, and split existing code where it makes sense (e.g. jobspec.py, list.py, etc.)? Or will that break the way flux.job methods are imported?

[SteVwonder]

I don't have much experience with Python module development, can we easily split job.py into multiple files by making a new directory src/bindings/python/flux/job with an init.py, and split existing code where it makes sense (e.g. jobspec.py, list.py, etc.)? Or will that break the way flux.job methods are imported?

Yep. You can do that. To preserve backwards-compatibility, I think we will need to add something like this to the job/__init__.py to pull all of the definitions into the flux.job "namespace":

from flux.job.jobspec import Jobspec, JobspecV1
from flux.job.id import id_parse, id_encode, JobID
from flux.job.control import *

where jobspec, id, and control are just strawman names for this example (I'm not certain that id will even work given that Python defines a bulit-in id).

[grondo]

Thanks! That was the hint I needed...