I think this section comparing to the previous date received from locations may need to be removed? Since we cant control the order of my.location

So, this will be slower, but thats the trade off for allowing any sort of location data as input

Its not trivial to cache the my.location.all function either, since it depends on any amount of inputs, so creating an accuracte cachew depends_on would be difficult

Hmm yeah, I mean in principle we could either demand the upstream providers to provide it as sorted (and for many it'll already be, like google takeout?).
Or alternatively sort before merging them in all (via a helper merge function), then the whole thing would be much more iterative. But I guess can think about it later

Or could even do some magic, e.g. function which takes multiple generator factories (functions () -> Iterator), assumes that they are emitting sorted values, and tries merging with https://docs.python.org/3/library/heapq.html#heapq.merge

If something out of order is detected, it starts from scratch with the offending factory wrapped in sorted (hence merging factories, not plain Iterators). I guess realistically it would very quickly lead to detecting which iterables are already sorted and which aren't, usually the order is either increasing, decreasing or just completely random?

Just leaving it here, but potentially might be useful for other data sources too, e.g. often it's kinda nice to get things according to timestamps

Yeah, use a heapmerge would make sense in situations like these, but I still think it might be prone to errors because a user might just overwrite all.py with something else (like I've done here) and then the magic doesn't work anymore. As usual, the magic might make it nice for us, but its not super extendible -- I feel like changing an all.py file shouldnt break a separate module

For now I think I'll go with the iterative approach of sorting the _locations in _iter_tzs -- since its cached when its used repeatedly

Could possibly add a sorted or geo location modules in the future which sort and use geopy to return more info about the locations

Another idea could be in all.py modules to specify the sources as a SOURCES = [ ] key at the toplevel, so then we could actually do some sort of magic and heapsort the iterators by querying that, instead of doing it in all.py itself. Otherwise, my.location.all.locations() is just a function and no way to get what the underlying iterators are. If the SOURCES var doesn't exist, then fallback to sorting the giant list of locations iteratively

And then locations in my.location.all would just be:

for provider in SOURCES:
    yield from provider()

Hmm yeah, I mean in principle we could either demand the upstream providers to provide it as sorted (and for many it'll already be, like google takeout?).
Or alternatively sort before merging them in all (via a helper merge function), then the whole thing would be much more iterative. But I guess can think about it later