Skip Navigation
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)LS
Posts
5
Comments
195
Joined
1 yr. ago
  • pydantic underneath (pydantic-base) is written in Rust. fastapi is fast cuz of pydantic. fastapi is extremely popular. Cuz it's right there in the word, fast. No matter how crap the usability is, the word fast will always win.

    If fastapi is fast then whatever is not fastapi is slow. And there is no convincing anyone otherwise so lets not even try.

    Therefore lets do fast. Cuz we already agreed slow would be bad.

    normal dataclasses is not fast and therefore it's bad. If it had a better marketing team this would be a different conversation.

    SQLModel combines pydantic and SQLAlchemy.

    At first i feel in love with the SQLModel docs. Then realized the eye wateringly beautiful docs are missing vital details, such as how to:

    1. create a Base without also creating a Model table
    2. overload tablename algo from the awful default cls.__name__.lower()
    3. support multiple databases each containing the same named table

    #2 is particularly nasty. SQLModel.new implementation consists of multiple metaclasses. So subclasses always inherit that worthless tablename implementation. And SQLAlchemy applies three decorators, so figuring out the right witchcraft to create the Descriptor is near impossible. pydantic doesn't support overriding tablename

    Then i came along

    After days of, lets be honest, hair loss and bouts of heavy drinking, posted the answer here.

    Required familiarity with pydantic, sqlalchemy, and SQLModel.

  • There is an expression, Linux isn't free it costs you your time. Which might be a counter argument against always using only what is built in.

    I'm super guilty of reinventing the wheel. But writing overly verbose code isn't fun either. Never seem to get very far.

  • people are forced to install dependencies

    This ^^.

    If possible, Python dependency management is a burden would prefer to avoid. Until can't, then be skilled at it!

    disclosure: i use/wrote wreck for Python dependency management.

    Compiled languages should really live within containers. At all cost, would like to avoid time consuming system updates! I can no longer install C programs cuz on OS partition ran out of hard disk space. Whereas Python packages can be installed on data storage partitions.

    for Python, I usually deliver the script as a single .py file I'm sure you are already aware of this. So forgive me if this is just being Captain Obvious.

    Even if the deliverable is a single .py file, there is support for specifying dependencies within module level comment block. (i forget the PEP #).

    I don’t like that (unless its a shell script, but that is by its nature a dependency hell) You and i could bond over a hatefest on shell scripts, but lets leave this as outside the discussion scope

    And your argument As the complexity of a .py script grows, very quickly, comes to a point the deliverable becoming a Python package. With the exceptions being projects which are: external language, low level, or simple. This .py script nonsense does not scale and is exceedingly rare to encounter. May be an indication of a old/dated or unmaintained project.

    From a random venv, installed scripts:

     undefined
        
    _black_version.py
    appdirs.py
    cfgv.py
    distutils-precedence.pth
    mccabe.py
    mypy_extensions.py
    nodeenv.py
    packaging_legacy_version.py
    pip_requirements_parser.py
    py.py
    pycodestyle.py
    pyi.py
    six.py
    typing_extensions.py
    
    
      
  • What is the root basis of your external package reluctance? Please explain cuz that's really where the juicy story lies.

    As technologists things change and advance and we have to adapt (or not) with the times. Maintaining the universe by ourselves is impossible, instead almost all of our tech choices are from what's available. And only if/when that is insufficient do we roll up our sleeves.

    More and more packages are using click. So there is a good chance if you look at your requirements .lock file that it's already a transitive dependency from another dependency.

    Or said another way, show me 5 popular packages that use argparse and not click and use dataclasses and not attrs

  • why click is based on optparse and not argparse

    Applies only to optional args long help

    Applies only to subcommands short help

    Special mention to how to document positional args. The docs explains the intentional lack of help kwarg for positional args.

     undefined
        
    ./thing.py -h
    ./thing.py subcommand --help
    
      

    Lists all the subcommands with one line short description for each subcommand.

    Lists detailed docs of one subcommand

    My opinion having used both argparse and click, click is simpler cleaner and less time consuming.

  • itter.sh - Social Media via SSH

  • No endless scroll of algorithmic 'content'

    That's not the case. According to the docs,

    itter watch [mine|all|#chan|@user] would entail infinite scrolling of content.

    itter timeline [mine|all|#chan|@user] [<page>] although there is pagenate the content list is potentially infinite

    Admit it! There is no search algorithm for content filtering or finding contacts or blocked users.

    Whatever the object is, there is no search algorithm to traverse it intelligently.

    For example, say i'm super popular but with a tendency to ghost everyone. Like a stereotypical LINE user faced with unpopular opinions or topics. So list of unfollow'ed (aka blocked) users is approaching infinity.

    A truly admirable dedication to being a really horrible human being.

    At the local bar, me and my mates have a drinking game where they think up random search criteria to see the kinda categories of people which have been blocked. A weak or nonexistent search algorithm would mean not likely to leave the bar on our feet.

    Show me chicks with green hair that posts about both climate doom and vaccines being great for children. Living in USA, Canada, or New Zealand. That has a cat avatar and has either giant earrings or nose piercing.

    That should be simple enough.

    yep look at that! i ghosted five green haired freaks. Now drink!

  • Appreciate feedback once you've had the chance to evaluate wreck.

    Feel free to make an issue. Which is the best way to catch my attention.

    In the CHANGES.rst, there are lists for both feature requests and known issues

  • wreck is a dependencies manager, which is venv aware, BUT is not a venv manager nor does it put dependencies into pyproject.toml. Sticks with good ol' requirement files.

    Assumes, for each package, it's normal to be working with several venv.

    Syncs the dependencies intended for the same venv.

     undefined
        
    req fix --venv-relpath='.venv'
    req fix --venv-relpath='.doc/.venv'
    
      

    Across many packages, unfortunately have to resort to manually sync'ing dependencies.

    Lessons learned

    • have very recently ceased putting build requirements into requirement files. The build requirements' transitive dependencies should be in the requirement files. wreck does not support this yet. i'm manually removing dependencies like: build wheel setuptools-scm (setuptools and pip already filtered out) and click.
    • syncing across packages is really time consuming. Go thru this pain, then no dependency hell.

    Wrote wreck cuz all the other options were combining requirements management with everything including the bathroom sink. build backends ... venv management ... everything goes into pyproject.toml. All these ideas seem to just compound the learning curve.

    Less is more especially when it comes to learning curve.

  • 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

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

  • 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

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

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

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

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

  • Python @programming.dev
    logging_strict @programming.dev

    Dependency management

    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?

    Python @programming.dev
    logging_strict @programming.dev

    Feedback on gh profile design

    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?

    Python @programming.dev
    logging_strict @programming.dev

    Whats in a Python tarball

    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?

    Python @programming.dev
    logging_strict @programming.dev

    PEP 735 does dependency group solve anything?

    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!

     undefined
        
    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?!

    Python @programming.dev
    logging_strict @programming.dev

    constraint vs requirement. What's the difference?

    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

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