logging_strict

joined 1 year ago
[–] logging_strict 1 points 5 days ago

Three-argument pow() now tries calling rpow() if necessary. Previously it was only called in two-argument pow() and the binary power operator. (Contributed by Serhiy Storchaka in gh-130104.)

that's a nail or wart that has been sticking out since forever

[–] logging_strict 1 points 5 days ago

read the beta release notes to find out

no spoilers from me

[–] logging_strict 1 points 1 week ago

another interesting thing is optimizing runtime using mypyc. This is how our dev toolchain is so quick.

mypy, flake8, isort, ... these kinda packages

Have never tried using mypyc would appreciate anyone sharing their experience with mypyc or other Python package compilers.

[–] logging_strict 1 points 1 week ago* (last edited 1 week ago)

That's what code reviews feel like. Don't take it personally. Sugar coating advice is a skill when working in groups.

Evidently i'm not, so got that code review advice the less than tender way.

Everyone one else was not critical and let these avoidable coding mistakes slide. That doesn't fill me with confidence. Should strive to spend more time testing code bases to eventually be able to see and avoid these kinda coding mistakes.

If anyone feels the need to set me on the road to becoming a lovable teddy bear full of positivity and group comradery, jawboning alone is too kind, feel free to put me in the hot chair by reviewing packages have written and published.

Have ordered the packages according to the value you'd gain by learning them.

logging-strict

wreck

pytest-logging-strict

sphinx-external-toc-strict

drain-swamp and drain-swamp-action

[–] logging_strict 1 points 1 week ago

Can see both the pros and cons.

Looking at existing packages we actually use, it's a mixed bag. When helping other projects, have not run into the situation where had to use ruff. Do see some uptake. It's not like a light switch there will be multiple commits before the ruff configuration is right. But i'm sure the configuration is simplier than the rocket science that is: black, flake8, isort, pre-compile, tox configurations.

Overtime expect Rust to bleed into the Python toolchain. The excuse to resist this is there is not enough time in the day for Python let alone other coding languages especially low level languages like Rust and integration of those low level languages and Python. Sounds like a ton of work unless intending to write Rust modules to optimize speed of complex Python apps.

[–] logging_strict 2 points 1 week ago (1 children)

So web scraping speed is at issue? I believe Python has beautifulsoup for web scrapping.

Unless it's for a learning experience, would recommend to not reinvent the wheel. Have been there done that too many times.

I feel like the village idiot cuz not properly learning that lesson.

[–] logging_strict 1 points 1 week ago

You picked up an STD from mvirts. That dodgy terminology has been passed on and added to your lexicon.

South Park suggested the cure for this, eat a banana. Life doesn't have to make sense, roll with it.

Quickly taking a shower was oddly never suggested.

[–] logging_strict 2 points 1 week ago

My name's not Shirley nor May. Meaning, the process guard has a name and it's not idiom.

[–] logging_strict 1 points 1 week ago

... or just trying to identify who will out themselves as Captain Obvious.

went off without a hitch

That was a, sorry not sorry

[–] logging_strict 1 points 1 week ago* (last edited 1 week ago)

Having multiple return statements in one function is a mistake. There shall ever be only one, unless that's unworkable due to tons of checks.

Cringe! That's like watching bad movies for the joy of really really bad movie moments. Watch Dead Snow II THEN Dead Snow I. Both are cringe. Former good cringe later really really bad cringe. Do not watch in chronological order.

A return statement within a while loop. Is that good or bad cringe?

Code with multiple return in one function/method screams noob. Especially when its completely unnecessary and avoidable. The return statement in random locations is a close 2nd.

The return statement in a while loop is just eyebrow raising. Like trying to write cringe, but forgot the threadpool, with GIL enabled, within the while on crack cocaine loop.

[–] logging_strict 1 points 1 week ago

or avoid the break all together; coverage hates break and continue.

is_found = False
while(on crack cocaine):
    if not is_found:
        do something
        is_found = True
    else:  # pragma: no cover
        pass
[–] logging_strict 1 points 1 week ago (2 children)

or not introducing another programming language into your toolchain by sticking with black, flake8, isort, and pre-commit

4
submitted 2 months ago* (last edited 2 months ago) by logging_strict to c/python
 

Market research

This post is only about dependency management, not package management, not build backends.

You know about these:

  • uv

  • poetry

  • pipenv

You are probably not familiar with:

  • pip-compile-multi

    (toposort, pip-tools)

You are defintely unfamiliar with:

  • wreck

    (pip-tools, pip-requirements-parser)

pip-compile-multi creates lock files. Has no concept of unlock files.

wreck produces both lock and unlock files. venv aware.

Both sync dependencies across requirement files

Both act only upon requirements files, not venv(s)

Up to speed with wreck

You are familiar with .in and .txt requirements files.

.txt is split out into .lock and .unlock. The later is for packages which are not apps.

Create .in files that are interlinked with -r and -c. No editable builds. No urls.

(If this is a deal breaker feel free to submit a PR)

pins files

pins-*.in are for common constraints. The huge advantage here is to document why?

Without the documentation even the devs has no idea whether or not the constraint is still required.

pins-*.in file are split up to tackle one issue. The beauty is the issue must be documented with enough details to bring yourself up to speed.

Explain the origin of the issue in terms a 6 year old can understand.

Configuration

python -m pip install wreck

This is logging-strict pyproject.toml


[tool.wreck]
create_pins_unlock = false

[[tool.wreck.venvs]]
venv_base_path = '.venv'
reqs = [
    'requirements/dev',
    'requirements/kit',
    'requirements/pip',
    'requirements/pip-tools',
    'requirements/prod',
    'requirements/manage',
    'requirements/mypy',
    'requirements/tox',
]

[[tool.wreck.venvs]]
venv_base_path = '.doc/.venv'
reqs = [
    'docs/requirements',
]

dynamic = [
    "optional-dependencies",
    "dependencies",
    "version",
]

[tool.setuptools.dynamic]
dependencies = { file = ["requirements/prod.unlock"] }
optional-dependencies.pip = { file = ["requirements/pip.lock"] }
optional-dependencies.pip_tools = { file = ["requirements/pip-tools.lock"] }
optional-dependencies.dev = { file = ["requirements/dev.lock"] }
optional-dependencies.manage = { file = ["requirements/manage.lock"] }
optional-dependencies.docs = { file = ["docs/requirements.lock"] }
version = {attr = "logging_strict._version.__version__"}

Look how short and simple that is.

The only thing you have to unlearn is being so timid.

More venvs. More constraints and requirements complexity.

Do it

mkdir -p .venv || :;
pyenv version > .venv/python-version
python -m venv .venv

mkdir -p .doc || :;
echo "3.10.14" > .doc/python-version
cd .doc && python -m venv .venv; cd - &>/dev/null

. .venv/bin/activate
# python -m pip install wreck
reqs fix --venv-relpath='.venv'

There will be no avoidable resolution conflicts.

Preferable to do this within tox-reqs.ini

Details

TOML file format expects paths to be single quoted. The paths are relative without the last file suffix.

If pyproject.toml not in the cwd, --path='path to pyproject.toml'

create_pins_unlock = false tells wreck to not produce .unlock files for pins-*.in files.

DANGER

This is not for a faint of heart. If you can avoid it. This is for the folks who often say, Oh really, hold my beer!

For pins that span venv, add the file suffix .shared

e.g. pins-typing.shared.in

wreck deals with one venv at a time. Files that span venv have to be dealt with manually and carefully.

Issues

  1. no support for editable builds

  2. no url support

  3. no hashs

  4. your eyes will tire and brains will splatter on the wall, from all the eye rolling after sifting thru endless posts on uv and poetry and none about pip-compile-multi or wreck

  5. Some folks love having all dependency managed within pyproject.toml These folks are deranged and its impossible to convince them otherwise. pyproject.toml is a config file, not a database. It should be read only.

  6. a docs link on pypi.org is 404. Luckily there are two docs links. Should really just fix that, but it's left like that to see if anyone notices. No one did.

4
submitted 3 months ago* (last edited 3 months ago) by logging_strict to c/python
 

Finally got around to creating a gh profile page

The design is to give activity insights on:

  • what Issues/PRs working on

  • future issues/PRs

  • for fun, show off package mascots

All out of ideas. Any suggestions? How did you improve your github profile?

14
submitted 3 months ago* (last edited 3 months ago) by logging_strict to c/python
 

From helping other projects have run across a fundamental issue which web searches have not given appropriate answers.

What should go in a tarball and what should not?

Is it only the build files, python code, and package data and nothing else?

Should it include tests/ folder?

Should it include development and configuration files?

Have seven published packages which include almost all the files and folders. Including:

.gitignore,

.gitattributes,

.github folder tree,

docs/,

tests/,

Makefile,

all config files,

all tox files,

pre-commit config file

My thinking is that the tarball should have everything needed to maintain the package, but this belief has been challenged. That the tarball is not appropriate for that.

Thoughts?

 

PEP 735 what is it's goal? Does it solve our dependency hell issue?

A deep dive and out comes this limitation

The mutual compatibility of Dependency Groups is not guaranteed.

-- https://peps.python.org/pep-0735/#lockfile-generation

Huh?! Why not?

mutual compatibility or go pound sand!

pip install -r requirements/dev.lock
pip install -r requirements/kit.lock -r requirements/manage.lock

The above code, purposefully, does not afford pip a fighting chance. If there are incompatibilities, it'll come out when trying randomized combinations.

Without a means to test for and guarantee mutual compatibility, end users will always find themselves in dependency hell.

Any combination of requirement files (or dependency groups), intended for the same venv, MUST always work!

What if this is scaled further, instead of one package, a chain of packages?!

11
submitted 5 months ago* (last edited 5 months ago) by logging_strict to c/python
 

In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).

Say have docs/requirements-pip-tools.in

-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in

...

The intent is compiling this would produce docs/requirements-pip-tool.txt

But there is confusion as to which flag to use. It's non-obvious.

constraint

Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!

Does not support:

  • editable mode (-e)

  • extras (e.g. coverage[toml])

Personal preference

  • always organize requirements files in folder(s)

  • don't prefix requirements files with requirements-, just doing it here

  • DRY principle applies; split out constraints which are shared.

view more: next ›