Thanks for the introduction to taskipy. Think if i need macros, Makefile is the way to go. Supports running targets in parallel and i like performing a check to ensure the virtual environment is activated or the command won't run.
.ONESHELL:
.DEFAULT_GOAL := help
SHELL := /bin/bash
APP_NAME := logging_strict
#virtual environment. If 0 issue warning
#Not activated:0
#activated: 1
ifeq ($(VIRTUAL_ENV),)
$(warning virtualenv not activated)
is_venv =
else
is_venv = 1
VENV_BIN := $(VIRTUAL_ENV)/bin
VENV_BIN_PYTHON := python3
PY_X_Y := $(shell $(VENV_BIN_PYTHON) -c 'import platform; t_ver = platform.python_version_tuple(); print(".".join(t_ver[:2]));')
endif
.PHONY: mypy
mypy: ## Static type checker (in strict mode)
ifeq ($(is_venv),1)
@$(VENV_BIN_PYTHON) -m mypy -p $(APP_NAME)
endif
make mypy without the virtualenv on will write a warning message why it's not working!
thanks for the head up on nox. Syntax seems like a tox meets pytest.
Are you using github actions locally? Feel silly making gh actions and workflows and only github runs them
If it's worth sharing it's worth to accompany the blog post with a repo containing unittests and tox.ini and pre-commit
If that had been done, tox would give feedback that match switch support is py310+
functools.singledispatch might be helpful to test multiple implementations
Complaint about sharing code within a blog post is the quality is ALWAYS suspect.
Lets leave crapoverflow.com style code examples in the past. Instead share tested code.
Also logging is not isolated. Bleeds all over the place. Which is a deal breaker
Not worth the endless time doing forensics
Agree! Lets stick with multiprocessing
one thread sounds nice. Lets do much more of that
that's pretty cool u are curating release announcements
Just activate the venv and then put it out of your mind. Can activate it with either a relative or absolute path. Doesn't matter which
The multiple venv for different Python versions sounds exactly like what tox does
Then setup a github action that does nightly builds. Which will catch issues caused by changes that only tested against one python version or on one platform
py313 is a good version to test against cuz there were many modules removed or depreciated or APIs changed
good luck. Hope some of my advice is helpful
BFF 1: Chuck is going to be so surprised. We've hired the best caterers, cosplay theme, fireworks, yard ales, twister themed blind laser tag, there will be balloons, ball pool, athletic challenge course, fabulous entertainment from top notch talent, show girls, the wine will flow like water
BFF 2: Tell me you didn't invite that grifter, mypy
BFF 1: I ... err ... hum. Opps
mypy enters the conversation
Don't use lambda use def function instead
BFF 2: Man i hate that guy. Rains on our parade and sucks the fun out of the room (and this entire thread).
Heard that only pyright, not mypy, has support for the new typing syntax
Wouldn't hurt to try out another static type checker. And if pyright is better. Switch.
Using mypy btw. Haven't moved on to support the new typing syntax