Adjustable attributes for get_psm3

[toddkarin]

iotools has a fixed ATTRIBUTES variable. I would like to be able to change this in get_psm3. Is there a reason we can't make attributes an input to the function get_psm3?

[kandersolar]

I've wanted the same thing. Note that you can change the ATTRIBUTES list before making the API call, so the functionality does exist, it's just a little awkward to use:

pvlib.iotools.psm3.ATTRIBUTES = [
    'ghi', 'dni', 'dhi', 'air_temperature', 'wind_speed', 'surface_albedo',
    'clearsky_dhi', 'clearsky_dni', 'clearsky_ghi', 'cloud_type'
]
meta, df = pvlib.iotools.get_psm3(40, -80, api_key, email, '2019', 30, True)

If anyone does open a PR for this, they could also edit the docstring to include 2019 and t*y-2019 in the list of acceptable years because those are available now.

[cwhanse]

Probably a good idea to add attributes as a kwarg, based on what I saw on the NSRDB webinar yesterday there are a number of new columns of data either available or soon to be added.

[kandersolar]

Taking a look at this as part of a general update to the PSM3 wrapper. I'm waffling on where a new attributes kwarg should be added in the signature. An optional parameter at the end, to maintain backwards compatibility? A new required parameter near the beginning? Input is welcome. Current signature for reference:

def get_psm3(latitude, longitude, api_key, email, names='tmy', interval=60,
             leap_day=False, full_name=PVLIB_PYTHON, affiliation=PVLIB_PYTHON,
             timeout=30):

[wholmgren]

I suggest attributes=ATTRIBUTES anywhere before timeout. I don't have any concerns about maintaining kwarg order for backward compatibility. I'm willing to consider a required argument if others think it's a good idea.