Closed tcj closed 2 years ago
@pieterbartsmit it's a little obscure — see #14
I originally "solved" the issue by commenting out a line -- see #16 -- but it was suggested on that PR to just remove it altogether. That's this PR. There may be a more elegant way to deal with this.
Even with the new pysofar 0.13 release, it still happens. My token only has readonly access to SPOT-0222. Witness:
tcj@mycomputer historical-data-pull % python3 ./historical-data-pull.py timj.csv
1 devices to query
request 1 of 1 (SPOT-0222):
{'wind': True, 'waves': True, 'frequency': True, 'track': True, 'surface_temp': True, 'smart_mooring': False}
Traceback (most recent call last):
File "./historical-data-pull.py", line 168, in <module>
get_data(request, api)
File "./historical-data-pull.py", line 102, in get_data
data = worker_wrapper((data_kind, [spot_request.spotID], str(spot_request.startDate), str(spot_request.endDate),{}))
File "/Users/tcj/Library/Python/3.8/lib/python/site-packages/pysofar/sofar.py", line 611, in worker_wrapper
worker_data = pool.map(_wrkr, queries)
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 364, in map
return self._map_async(func, iterable, mapstar, chunksize).get()
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 771, in get
raise self._value
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 48, in mapstar
return list(map(*args))
File "/Users/tcj/Library/Python/3.8/lib/python/site-packages/pysofar/sofar.py", line 653, in _helper
lim = _query['limit']
KeyError: 'limit'
The lim
variable is only used by commented-out code later on in the method in which it lives, so it seems harmless to remove at this time.
…on non-"owned" devices
Addressing #14
Replaces #16