consistent air temperature naming

[wholmgren]

A lot of pvlib uses the term temp_air for ~2 m air temperature. The get_solarposition function (perhaps among others) uses temperature, which causes some confusion (see #893 (comment)). We should standardize the naming.

My vote is temperature. I really dislike temp_air.

Note that MetPy recently went through a similar parameter name refactoring and chose temperature (among other things): Unidata/MetPy#1299

[mikofski]

I'm okay with temperature for dry bulb temperature, and then just dew_point for dew point temperature. Are there any other potential conflicts?

[cwhanse]

I can accede to temperature for ambient temperature for compatibility with metpy and I'm OK with dew_point. We should also agree on names for the other temperature quantities: cell temperature (currently temp_cell in functions, cell_temperature attribute of ModelChain), module temperature (unnamed), (future) inverter temperature (unnamed). Do we distinguish between dry-bulb and wet-bulb air temperatures?

[mikofski]

I guess I prefer cell_temperature but I think a style guide is appropriate here:

• One style seems to be the main property name first, eg: temp subscripted by some qualifier like _air or _cell
• The other style seems to be more verbose and just uses plain human readable terms, replacing spaces with underscores like, cell_temperature, absolute_airmass, or dew_point

We should just pick a style, explain it as best as we can, ask that it be followed, keep a record of standardized terminology, and hope that it's mostly general enough. Sound good? This could possibly be a GSoC task, but maybe too easy?

[CameronTStark]

@mikofski I generally prefer the first style you list but with the qualifier to be first. This makes it easier to find the variable in an IDE's auto-completion when you might have six different temperatures in the form temp_xyz, temp_abc, etc. as opposed to typing x + TAB and getting right to xyz_temp.

I'm fine with your second style as long as a third full length word isn't added to the snake-cased variable. Sometimes it really helps to have it easily human readable.

If I see just temperature I immediately wonder "what temperature?". Having the qualifier without having to base it on the context of the function is preferable.

[wholmgren]

To be clear, I only care about naming for the public API. Use whatever you want within functions so long as it's readable.

The other style seems to be more verbose and just uses plain human readable terms, replacung spaces with underscores like, cell_temperature, absolute_airmass, or dew_point

+1

I think we're safe to assume that temperature or air_temperature is a dry bulb temperature. I'm not aware of any functions that care about wet bulb temperature.

I also prefer dew_point over dew_point_temperature

[cwhanse]

I think it would help to compile a glossary of what's currently used in the API, by topic. I can take a crack at that.