import-linter VS python-feedstock

Never heard of https://import-linter.readthedocs.io/ before. Not sure if I like this type of solution, but it's interesting, and certainly the problem is real.

Before clicking on this, I expected to see import-linter [0] which achieves something very similar but with, in my opinion, a bit less magic. Another solution in a similar spirit is Pants [1], though this is actually a build system which allows you to constrain dependencies between different artifacts (e.g. which modules are allowed to depend on which modules).

To Sourcery's credit, their product looks much more in the realm of "developer experience" -- closer to Copilot (or what I understand of it) than to import-linter. Props to them for at least having a page about security [2] and building a solution which doesn't inherently require all of your source code to be shared with a vendor's server.

[0] https://github.com/seddonym/import-linter

[1] https://www.pantsbuild.org/

[2] https://docs.sourcery.ai/Product/Permissions-and-Security/

import-linter on GitHub

It's already there:

https://anaconda.org/conda-forge/python

https://github.com/conda-forge/python-feedstock/pull/577

Using mamba to create a new encoding called py311 with python 3.11:

    mamba create -n py311 python=3.11

https://news.ycombinator.com/item?id=18040664

Today, conda-forge compiles CPython to relocatable platform+architecture-specific binaries with LLVM. https://github.com/conda-forge/python-feedstock/blob/master/...

Pyodide (JupyterLite) compiles CPython to WASM (or LLVM IR?) with LLVM/emscripten IIRC. Hopefully there's a clear way to implement the new GIL-less multithreading support with Web Workers in WASM, too?

The https://rapids.ai/ org has a bunch a fast Python for HPC; with Dask and pick a scheduler. Less process overhead and less need for interprocess locking of memory handles that transgress contexts due to a new GIL removal approach would be even faster than debuggable one process per core Python.