The primary purpose of those buttons is of course to let those sites track everyone’s browsing activity across every site that uses them, which does not require that anyone ever click on them.
Even if less than 0.0001% of people click them, anyone with an SEO/spammer “grindset” will assure site operators that the potential benefit of someone sharing a link they otherwise wouldn’t have is still at least theoretically non-zero. And, since there is absolutely no cost at all besides an acceptable number of extra milliseconds per pageload, really, it would be downright irresponsible not to have them there!
Nice work! Here are a few notes:
The
WeatherApp
object has a mix of attributes with long-term (egself.LOCATIONS
) and short-term (egself.city
) relevance. Instance attributes introduced in places other than__init__
, which makes it non-trivial for a reader to quickly understand what the object contains. And, actually,self.{city,lat,lon}
are all only used from theadd_city
method so they could/should be local variables instead of instance attributes (just remove theself.
from them).There seem to maybe be some bugs around when things are lowercase and when not; for example checking
if self.city.lower() in self.LOCATIONS
but then when writing there the non-lowerself.ctiy
is used as the key toself.LOCATIONS
.The code under
if rep == "1"
andelif rep == "2"
is mostly duplicated, and there is noelse
branch to cover ifrep
is something other than 1 or 2.It looks like the config only persists favorites so far (and not non-favorite cities which the user can add) which isn’t obvious from the user interface.
Passing both
location
andlocations
intoWeatherAPI
so that it can look uplocations[location]
is unnecessary; it would be clearer to pass in the dict for the specific location. It would also be possible to avoid the need forLOWLOCATIONS
by adding a non-lowercasename
key to the per-location dictionaries that just havelat
andlon
right now, and then keepingLOCATIONS
keyed by the lowercase names.HTH! happy hacking :)