ncdulo/weather_cli

[Feature Request] Templates for `pretty` formats

Closed this issue · 0 comments

Is your feature request related to a problem? Please describe.
Depending on how you look at it, this could be classed as a bug, or a feature (request). For now, I lean towards calling it a feature request as it is more fixing design issues with the current implementation as opposed to fixing incorrect operation.

Currently, the output string in current() is assembled through a lot of dirty string concatenation. Chaining strings together as we go through our flags. This mostly works. However, I have been running into places where I have trouble extending the code. Or having a hard time when trying to add additional --pretty formats. The current implementation does the bare minimum to just work, but nothing extra in the way of allowing for future expansion.

Describe the solution you'd like
I would like to utilize the string.Template class to handle out output format. This will allow us to build a collection of output templates, and then substitute in OpenWeatherMap data. I am wondering how best to handle the cases where certain pieces of data are missing. I think either silently skipping that parameter, or initializing it to a NaN-type value would handle it. The latter is probably preferable.

Describe alternatives you've considered
The alternative solution is to keep banging away with string concatenation and hard to maintain code. Don't do that.

Additional context
The implementation described here will require an update of the --pretty flag into an option. It will also require updating each if {conditions,temperature,...} block within the current() function so that they assign to their own variable, instead of the output string. Whether we should over-write the same variable that we test for with the output string is yet to be determined. An example being:

# This
if conditions:
    conditions = 'partly cloudy'
# Or this
if conditions:
    conditions_text = 'partly cloudy'
else:
    conditions_text = None

I tend to lean towards the latter solution, otherwise we will need to check for potential True values being given to our output template when the flag is enabled, but the data is unavailable. That is an issue I ran into before when trying a very early implementation of this feature. That attempt was not well thought through and resulted in more problems than solutions. I unfortunately did not think to save the work and simply git reset it out of existence.