- All programmers are API designers. Good programs are modular, and intermodular boundaries define APIs. Good modules get reused.
- APIs can be among your greatest assets or liabilities. Good APIs create long-term customers; bad ones create long-term support nightmares.
- Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best.
- APIs should be easy to use and hard to misuse. It should be easy to do simple things; possible to do complex things; and impossible, or at least difficult, to do wrong things.
- APIs should be self-documenting: It should rarely require documentation to read code written to a good API. In fact, it should rarely require documentation to write it.
- When designing an API, first gather requirements--with a healthy degree of skepticism. People often provide solutions; it's your job to ferret out the underlying problems and find the best solutions.
- Structure requirements as use-cases: they are the yardstick agai
The Zen of Python (PEP 20)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"""TimeZone is an immutable (frozen) tzinfo implementation with *nice* offsets: utc[+2:00], utc[+1:30].""" | |
__author__ = "Misha Drachuk" | |
__license__ = "MIT" | |
from dataclasses import dataclass, field | |
from datetime import timezone, timedelta, tzinfo, datetime | |
from math import copysign | |