logging_strict

joined 8 months ago
[–] logging_strict@programming.dev 1 points 1 day ago (1 children)

U are not wrong.

Dependency management is tough and often frustrating. Dealing with resolving dependency conflicts is unavoidable. This area is a constant focus of development, so could see improvements over time.

Some packages to keep an eye on:

pip & setuptools

pip-tools (specifically pip-compile)

https://pypi.org/project/pip-compile-multi/

poetry

Any others i've missed?

[–] logging_strict@programming.dev 1 points 2 days ago (1 children)

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.

[–] logging_strict@programming.dev 1 points 4 days ago (3 children)

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

[–] logging_strict@programming.dev 1 points 4 months ago

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

[–] logging_strict@programming.dev 1 points 4 months ago (6 children)

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

[–] logging_strict@programming.dev 1 points 6 months ago

LPython will be obsoleted by Mojo

[–] logging_strict@programming.dev 1 points 6 months ago* (last edited 6 months ago)

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).

view more: next ›