• anticurrent@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    12 hours ago

    Is this gonna make Django run as fast as node.js frameworks? cause this is the only thing stopping me from switching to python

  • onlinepersona
    link
    fedilink
    arrow-up
    1
    ·
    23 hours ago

    Why wasn’t free threading a new version of python? Having everything suddenly going from thread safe to C level insecurity is a major change, not just a small feature update. In fact, if they had to redactor the interpreter to support it, that sounds like even more of a reason to make it a major version update. Doesn’t python follow semver?

    Anti Commercial-AI license

    • bitcrafter
      link
      fedilink
      arrow-up
      2
      ·
      2 hours ago

      Why wasn’t free threading a new version of python?

      It was part of the 3.13 release.

      Having everything suddenly going from thread safe to C level insecurity is a major change, not just a small feature update.

      Sure, which is why it this behavior currently considered experimental and is not enabled by default; if you want to try it out, you have to specifically enable it when building Python from sources.

      In fact, if they had to redactor the interpreter to support it, that sounds like even more of a reason to make it a major version update. Doesn’t python follow semver?

      No, currently releases follow a regular schedule and every release bumps the second number and keeps the first.

    • zagaberoo@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      22 hours ago

      The free-threaded build is a patched version of the interpreter. This is not (currently) behavior normal users will be exposed to.

  • fubarx@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    2 days ago

    Many applications will be waiting until cryptography and psycopg add GIL-free support.

  • flandish@lemmy.world
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    2 days ago

    as someone fairly new to larger python projects, working in a team too - why does it seem like I’m always in dependency hell? Sometimes things work with venv until I forget and a notebook needs something else. Or a diff type of proj because mlflow wanted another kind of env manager?

      • flandish@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        1 day ago

        i reckon that’s mostly it - I get an idea, wanna try something and don’t “reset” to a fresh venv. or I do then forget to reinstall the tools I want to use cause I was “just” using them in this same terminal.

        it’s me not python. though it’s funny getting a few replies with different solutions. like in PERL, tmtowtdi.

        thanks for your reply!

    • Incblob@lemmy.world
      link
      fedilink
      arrow-up
      7
      ·
      2 days ago

      6 years of python and I’ve never really had that problem, also working on larger projects. Use poetry or uv and you’ll probably be fine. Unless you’re doing something strange with your dependencies. The only thing I would say is non trivial is updating the dependencies. And if a library has a bug or something you have to downgrade for. You can specify dev dependencies for notebooks and such. I’ve not heard of mlflow having a problem with a manager. Perhaps you’re in a cloud environment and don’t have access to poetry for example?

      • flandish@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        2 days ago

        never used poetry. just venv, virtualenv and such. I guess I just don’t know the current era’s idiomatic way of doing things. I’m more familiar with java/mvn, rust, etc. It seems like every manning book on a pythonic tool has a different way the author setup the env. to be expected sure. I just need to grok and settle into my own. :)

        just learning is all. :) appreciate the reply!

        • sugar_in_your_tea@sh.itjust.works
          link
          fedilink
          arrow-up
          5
          ·
          2 days ago

          Poetry/uv is similar to Rust’s cargo. You specify your direct dependencies in a TOML file and their version constraints and the tool takes care of the rest.

    • somegeek
      link
      fedilink
      arrow-up
      4
      ·
      2 days ago

      That’s one of the main pain points of Python. Something like poetry or uv can help but the python ecosystem is just unstable. It’s very hard to update a dependancy. You project might only run with very specific versions of libraries and the language itself.

      I honestly hate that about python and I don’t think python is good for developing large software. Even js/ts is a much better ecosystem. (I’m bracing for the hate)

      • flandish@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        2 days ago

        hrm. yeah. I am “trying on” some basic ml models (just simple classifications) into our workflow and while I can whip one up with scikit, a notebook, and serve it with flask/fast - there is no way I can build a workflow tenable for others who are more “data analytics” than coders. The ecosystems for low/no code model generation (knime etc) with handoff to engineers like me to serve is … young.

    • rutrum
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 days ago

      If you use conda, I suggest using pixi as a project manager. It has lock files which will fix dependencies, and it can activate your enviroments with scripts and variables defined in your pyproject.toml. It has been so much better than using conda directly: https://pixi.sh/

    • logging_strict
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      2 days ago

      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.

      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.

    • esa@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      2 days ago

      You’ll likely also want to check out ruff for linting and formatting, by the same company that makes uv. It doesn’t enable a lot of lints by default, but there’s a long list of checks to enable.

      They also have a typechecker, ty, which is still in early alpha. If it’s as good as their other tools I expect it to become the standard for typechecking Python. Currently you’ll likely want to go with pyright for that.