-
Notifications
You must be signed in to change notification settings - Fork 175
PyOWM version 3
Claudio Sparpaglione edited this page May 21, 2019
·
53 revisions
This is meant to be a manifest for PyOWM version 3
- Ask the community to prioritize new v3 features
- Ask the community to propose new features for v3
- Ask the community help with development of support for paid OWM APIs features
- Agro APIs
- Polygons
- Soil
- Satellite Imagery
- MORE TBD
- Weather API --> transition to Agro weather API???
- Stations API
- UV Index API
- Air Pollution API
- Weather Alerts API
- Map tiles
drops legacy support for Python2 and support for Python 3.4only supports py37+ (therefore also the new py38)
give theweatherapi
module exactly the same dignity as other api modules...finalize deprecations already foreseen for v3dict configurationremove caches: pyowm won't feature any caching mechanism, that will be on the client's- ability to inject a custom Logger
- make a consistent Exceptions hierarchy and use it
- async/awaitable API calls
- HTTP/SOCKS proxies support
- installable on Linux also via
apt
andrpm
No more Dockerfiles or Docker imagesHTTP calls timeout is increased to 5 seconds (to allow to safely download satellite images)
both will feature a Manager object, which will be instantiated by the new OWM entry point
dropped old PyOWM history retrieval features as today they're usable only with OWM paid plans- rename weather forecast functions
- Refactor
CityIDRegistry
tocommons
- migration guide from V2 to V3
- remove most of the development-oriented docs: users tipically don't care about it
- add code recipes and corresponding integration tests
- document PyOWM 2 maintenance timeline
- Wiki pages must NOT serve as documentation sources! Therefore docs-like pages must be removed and links to them shall be replaced to links to the actual Readthedocs documentation pages
write an automation script to generate boilerplate code for new entitiesremove XML schemas and XML dumps for entitiesremove JSON dumps for entities (only Python dict dumps will be allowed)- remove all Java style getter methods (eg.
get_temperature
), so to allow Pythonic access to obj attributes - all entities shall have methods:
__repr__
,from_dict
,to_dict
do we really need parsers when we havefrom_dict
methods??? If not, these can be droppedclean modules style: add shebangs, file econding, order imports alphabetically