arthur-st

Yes, that's essentially the only practical reason.

Self-hosted Gitea is a good time if you're comfortable taking care of backups and other self-hosting stuff.

There are two Graphite companies. The time series DB for metrics (not this) and the stacked diff code review platform (this). Looking at other comments under the post, they seem to have executed a hard AI pivot recently.

For real. I consider myself to be “into Python typing,” and yet I had no knowledge of Zuban before the parent comment and a very faint memory of Jedi.

I mean, that is what the term implies.

OpenAI is BYOK-only on OpenRouter, which artificially depresses its utilization there.

It is exactly that

To be fair, you do get enums and pattern matching from base language.

4o on ChatGPT.com vs. Opus in an IDE is like cooking food without kitchen tools vs. using them. 4o is neither a coding-optimized model nor a reasoning model in general.

I did work for a Russian financial multinational just before COVID-19, as a native Russian speaker, and it was a free-for-all mess interally. The IT side had a load-bearing, old-school sysadmin type with a personality for heroics.

Aider has been doing that for a long time now, it was the first project to do this afaik.

They have a healthy enterprise customer base, and an engineering team that clearly knows how to work with power users (which OpenAI is bad at).

They have an old-school enterprise sales operation that is doing superb work. Apart from that, ChatGPT's projects are useless crap (can't read other convos in a project; can't generate project documents from a convo), and so clearly they would get value out of just getting some developers who have built anything of use to a poweruser.

Having experience with digitizing a university textbook in physics by hand, this is a very nice LaTeX guide for everyone interested. One thing worth noting from 2025 perspective that the "default" local setup is most likely going to be VSCode with LaTeX Workshop[1] and LTeX+[2] extensions, and that you should use TeX Live on every platform supported by it (since MiKTeX and friends can lag). Also, use LuaTeX, as it's the officially recommended[3] engine since November 2024.

[1] https://marketplace.visualstudio.com/items?itemName=James-Yu...

[2] https://marketplace.visualstudio.com/items?itemName=ltex-plu...

[3] https://www.texdev.net/2024/11/05/engine-news-from-the-latex...

No, the parent clearly indicates that they consider XeTeX a worse choice than LuaTeX.

They weren't contributing before

That is not true. Companies like AWS had paid staff working as OSS Redis core maintainers before the licencing schism. This talk of "achieving their goals" is just bluster serving no reason other than damage control.

Pyright has semantic improvements (and also some differences) over MyPy. As for using the type checker as a language server, it's difficult to go back to “it's compiling” after you've had one stop you from typing bugs out in-flight.

Check if your configuration allows pyright to use other files in the workspace.

To round out the big 4, there's also Pyre from Meta. I haven't used it myself, as when I last checked it had a low number of PEPs covered, but I've heard some good words for it.

MyPy's rules are reference-grade, being as close to an official spec as we get until the Typing Council is done establishing their moat.

To understand shortcomings of MyPy, I strongly suggest reading pyright's documentation for how they compare: https://github.com/microsoft/pyright/blob/main/docs/mypy-com...

Quoting the pertinent part:

Pyright was designed with performance in mind. It is not unusual for pyright to be 3x to 5x faster than mypy when type checking large code bases. Some of its design decisions were motivated by this goal.

Pyright was also designed to be used as the foundation for a Python language server. Language servers provide interactive programming features such as completion suggestions, function signature help, type information on hover, semantic-aware search, semantic-aware renaming, semantic token coloring, refactoring tools, etc. For a good user experience, these features require highly responsive type evaluation performance during interactive code modification. They also require type evaluation to work on code that is incomplete and contains syntax errors.

To achieve these design goals, pyright is implemented as a “lazy” or “just-in-time” type evaluator. Rather than analyzing all code in a module from top to bottom, it is able to evaluate the type of an arbitrary identifier anywhere within a module. If the type of that identifier depends on the types of other expressions or symbols, pyright recursively evaluates those in turn until it has enough information to determine the type of the target identifier. By comparison, mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge.

Pyright implements its own parser, which recovers gracefully from syntax errors and continues parsing the remainder of the source file. By comparison, mypy uses the parser built in to the Python interpreter, and it does not support recovery after a syntax error. This also means that when you run mypy on an older version of Python, it cannot support newer language features that require grammar changes.

Astral's type checker seems to an exercise in speeding up Pyright's approach to designing a type checker, and removing the Node dependency from it.

This depends on the model, e.g., the non-entry level Forerunner series watches have had training load-related metrics for a while now. That said, Garmin is mainly a cardio watch, and by extension the Apple training load metrics seems to be giving a more presentable UX to the "default"[1] approach to cardio training load.

[1] https://evokeendurance.com/a-new-and-better-look-at-training...

This was interesting, cheers!

especially after ... the white house praise for rust

What's the threat model here, that Rust is a trojan language from the feds?

Speaking about strictly PyTorch, it's actually elementary on the distribution side. I know that there are packages which do some weird setup magic at runtime, unfortunately, but pytorch is not one of them.

Installing it via the PyPI gets you the CPU version on Windows/macOS, and CUDA 12.1 on Linux. You can specify CUDA version explicitly, which you need to get CUDA on Windows, or CUDA 11.8 on Linux, by referencing the corresponding PyTorch package index, e.g., https://download.pytorch.org/whl/cu118 - cu118 means CUDA 11.8. Doing that explicitly is the normal practice, since in ML land you'll know your hardware well - no one is asking for tooling that automatically resolves CUDA/cuDNN/etcetra compatibility.

Hence, it hopefully follows that installing this with pip is trivial, you just need to maintain multiple requirements.txt files so that you specify the correct index URL where it's necessary. What I specifically want, then, is for someone to give me a UX where I don't have to maintain these requirements.txt files. I should be able to just specify arbitrary build environments* in pyproject.toml, and override the global default package index for specific packages in [platform-]specific build environments.

*Really, we're probably talking about combining blocks of optional dependencies into an ersatz build environment, but that's what they ultimately are for.

If I can then "compile" these build environments into properly reproducible lock files, and then use the dependency manager to export these lock files into conventional requirements.txt files with exact pins, then we've arrived at what I would call a good UX for specifying dependencies in Python.

To the best of my knowledge, for 99.9% of packages this doesn't require Docker. Different parts of this process work well across the ecosystem, just not as a matter of full package. To name a few

- Poetry has many building blocks, but just has had a questionable implementation as per parent you're replying to, and also random other problems like not working at all with private indexes back when I tried, and so on;

- pip-tools does the entire pipeline well, but it quite unfortunately doesn't support cross-platform targeting;

So, quite honestly, until someone can do this correctly and in one place - and, ideally, with endorsements from PSF and PyPA - I'll just consider Python dependency management tooling to be inadequate for my use cases.

Unfortunately, installing pytorch via Poetry was not for the faint of heart, last I tried. [1]

For example, it used to download wheels for all matching distributions (say pytorch for a few platforms) to get metadata. That would be like a 10 GB download for 4 wheels of pytorch, to generate the lockfile.

Another thing it used to do is ignore local cache, so for some locking operations would download the same wheel multiple times.

In general, it was not entertaining, from an ML practitioner's perspective, to infer an attitude from the Poetry maintainers that the mountain shall come to Muhammad, so to say. Their abridged position was that pytorch is not compliant with standards, when Poetry itself, e.g., is not PEP 440-compliant, in a manner pertinent to the issue at hand. [2]

I realise that my grumbling about pytorch has nothing to do with your perfectly adequate comment, that said. Please interpret it as nothing more than an expanded rationale fore being more interested in learning about Rye/uv than in revisiting Poetry, at least for the projects I've worked on.

[1] https://github.com/python-poetry/poetry/issues/6409

[2] https://github.com/python-poetry/poetry/issues/7748

Well, that's my question - I'm not familiar with Rye/uv, and I'm curious to know if it can substantively simplify the workflows that I'm aware of. I simply clarified to pre-empt a potential comment about Docker.

I guess I'll add that this is mostly possible using a Docker-based workflow, but the hope is that one day we could get something more lightweight.

Any ongoing work/plans to follow for cross-platform lock files?

This is one concern that would prevent the team I'm on from moving. We do ML work, so I'll use a pytorch-based project for my example. The desired state is that all dependencies are in pyproject.toml, e.g., from which you can generate a set of lockfiles from an AArch64 Mac or an AMD64 Windows workstation for the following platform configurations:

1. Mac with default (MPS) pytorch

2. Windows with CUDA pytorch

3. AArch64 Linux with CPU pytorch

4. AMD64 Linux with CPU pytorch

5. AMD64 Linux with CUDA pytorch

P.S. Big thanks for making Ruff, we're huge fans of linting and formatting both.

It’s worth noting that ePrivacy directive is an EU directive, in contrast to GDPR being an EU regulation.

Inconsistent enforcement is a feature of directives. The comment on the GDPR though is full-well valid.

I have, and I am indeed very hopeful about the WWDC 2024-related Swift announcements. My comment was meant to illustrate my thinking circa a year or two ago.