To use the package you’re working on directly in the project itself. Go to the directory where your package is being developed, where the pyproject.toml file resides:
poetry install
poetry shellI fought days with it and it ended up being that simple. *Facepalm*.
If necessary, remove the previously created venv first.
To use it in a different project though, you’d probably need something like this.
I got curious about what actually is a blocker in terms of time complexity, for python. I’ve always known that the smaller the complexity the better, but it’s never quantitative. How bad is n^2? How bad is n^n? How much of an improvement is sqrt(n) or log(n)? What is outrageous to write and is absolutely no-go?
Either with pip:
pip install git+https://github.com/psf/black.git@1aa4d5bOr with pipx, which looks like a python equivalent of npx, and allows direct runs without installation, or for multiple versions to co-exist:
pipx install git+https://github.com/psf/black.git@1aa4d5bRef: [1]
A bit of a hack. So that whenever there is a request, its response will be recorded:
@pytest.fixture(autouse=True)
def stripe_vcr(vcr, request):
filename = f"{request.function.__module__}/{request.node.name}.yaml"
with vcr._use_cassette(path=filename):
yieldhttps://pytest-vcr.readthedocs.io/en/latest/configuration/#vcr
In simple terms:
flush and commit, later queries will be able to retrieve these changes.flush() changes are in a pending state (no db statements are issued yet), and can be undone by rollback(); commits are persisted to db and non-reversible.Why use flush:
Error running pre-commit:
Type tag 'jupyter' is not recognized. Try upgrading identify and pre-commit?>>> dance.__name__
'dance'>>> callable(foo)
True/False2 Errors that were painful to debug.
Continue readingDomain Driven Design basically means to let business logic decide on object model, and construct the rest of the code from that starting point. Instead of, say, starting off by designing db schema and build from grounds up.
Continue readingAnd, what is the difference between raising normal errors and assertions? Basically:
| Raising Error | Assertion |
Raise ValueError('Input not in range [1, 10]') | assert 1 <= v <= 10 |
| Intended for users | Intended for developers |
| Happens when user action is illegal | Happens when code contains bug |
| To signal to user to take a different course of action | To easily find where code starts to error |
| Cannot and should not be disabled | Can be disabled during compilation, therefore should not be used in logics like data validation |