ofek

Relatedly, I wish I could bring my electric wheelchair with me in the cabin. I went on a work trip to Paris in April and sitting in a regular seat was just as uncomfortable as I remember. Fortunately, halfway through the first flight one of the attendants noticed my caregiver frequently repositioning me and had the other person in our row move elsewhere so that I could lie down across two seats. American Airlines allowed me to do that on the return flight as well.

I was quite worried that my wheelchair would break in some way like I've experienced several times before but everything went quite smoothly! AI helped tremendously with planning, e.g. here's Claude: https://claude.ai/public/artifacts/6c977d23-1b7c-4a00-a7aa-d...

Thanks for the clarification! I'm sure your team is already aware but Windows users perceive support as native binaries (no WSL) that can run in a normal environment (no Git Bash or Linux utilities).

I won't be able to fully test because the interactive prompt gates on the user having an advanced subscription (I already pay $40 a month) which for now doesn't seem to be worth it.

However, the TUI as shown in a post [0] by one of their engineers is quite beautiful. For a moment I thought it was written in Python because it looks similar to Textual [1] but I inspected the binary for my platform [2] and it seems to be written in Rust. I guess Ratatui is quite customizable!

The state of its Windows support is unclear to me. The Bash installer script [3] has a comment on top that says "Windows: run under Git for Windows / MSYS2 Bash (same curl | bash flow); WSL uses the Linux binary." I ran the binary normally in a Nushell session and didn't encounter any issue other than a start-up time that was slower than expected on the first run. Perhaps I would have seen issues had I gotten past the login step.

[0]: https://x.com/skcd42/status/2054993372662915183

[1]: https://github.com/Textualize/textual

[2]: https://storage.googleapis.com/grok-build-public-artifacts/c...

[3]: https://x.ai/cli/install.sh

I shared the author's frustration when figuring out how to ship such binaries to end users so I wrote a guide [0] detailing exactly how to do it. Apple's documentation is surprisingly poor and I couldn't find any blog posts so I ended up reverse engineering what works via trial and error as well as popular OSS projects on GitHub.

[0]: https://ofek.dev/words/guides/2025-05-13-distributing-comman...

If an agreement can't be reached with your new employer are you certain that folks at Microsoft will continue maintaining this library? I'd like to experiment with it but have trepidation regarding future development.

The naming of this project is quite unfortunate as it resembles the Simplex [1] specification for guiding agent development, which does look promising in comparison.

[1]: https://github.com/thinkwright/simplex

I'd encourage folks to read the recently-published statement [1] about the state of OpenSSL from Python's cryptography project.

[1]: https://news.ycombinator.com/item?id=46624352

Indeed, I introduced this [0] as an option for every Python integration that runs on the Datadog Agent.

[0]: https://github.com/DataDog/integrations-core/pull/12986

The post is entirely authentic; it matches the writing style of the author from before the LLM boom and discusses work that the human author recently released. Can you pinpoint what makes you feel that way?

edit: I asked for explanation before the post was edited to expand on that. I disagree but am sympathetic to the weariness of reading content now that AI use is widespread.

Your C extension guide looks very useful and I quite like the foreword/history behind it. Have you considered updating the resource to account for the freethreaded mode (which will eventually become the default) on 3.14+?

This is awesome, thanks a lot! I'm going to introduce this in the test suites of the extension modules I maintain [0][1] and, if all goes well, eventually at work [2].

I really appreciate the support for Windows as that platform is currently underserved [3] when it comes to such memory tooling.

[0]: https://github.com/jcrist/msgspec

[1]: https://github.com/ofek/coincurve

[2]: https://github.com/DataDog/integrations-core

[3]: https://github.com/bloomberg/memray

> pip could implement parallel downloads, global caching, and metadata-only resolution tomorrow. It doesn’t, largely because backwards compatibility with fifteen years of edge cases takes precedence.

pip is simply difficult to maintain. Backward compatibility concerns surely contribute to that but also there are other factors, like an older project having to satisfy the needs of modern times.

For example, my employer (Datadog) allowed me and two other engineers to improve various aspects of Python packaging for nearly an entire quarter. One of the items was to satisfy a few long-standing pip feature requests. I discovered that the cross-platform resolution feature I considered most important is basically incompatible [1] with the current code base. Maintainers would have to decide which path they prefer.

[1]: https://github.com/pypa/pip/issues/13111

This release wouldn’t have been possible without Cary, our new co-maintainer. He picked up my unfinished workspaces branch and made it production-ready, added SBOM support to Hatchling, and landed a bunch of PRs from contributors!

My motivation took a big hit last year, in large part due to improper use of social media: I simply didn’t realize that continued mass evangelism is required nowadays. This led to some of our novel features being attributed to other tools when in fact Hatch was months ahead. I’m sorry to say that this greatly discouraged me and I let it affect maintenance. I tried to come back on several occasions but could only make incremental progress on the workspaces branch because I had to relearn the code each time. I’ve been having to make all recent releases from a branch based on an old commit because there were many prerequisite changes that were merged and couldn’t be released as is.

Development will be much more rapid now, even better than the way it used to be. We are very excited for upcoming features!

Here's an example of Gemini 2.5 Pro hallucinating, which happens so much that I don't trust it https://gemini.google.com/share/99a1be550763

The sentiment in this thread surprises me a great deal. For me, Gemini 2.5 Pro is markedly worse than GPT-5 Thinking along every axis of hallucinations, rigidity in its self-assured correctness and sycophancy. Claude Opus used to be marginally better but now Claude Sonnet 4.5 is far better, although not quite on par with GPT-5 Thinking.

I frequently ask the same question side-by-side to all 3 and the only situation in which I sometimes prefer Gemini 2.5 Pro is when making lifestyle choices, like explaining item descriptions on Doordash that aren't in English.

edit: It's more of a system prompt issue but I despise the verbosity of Gemini 2.5 Pro's responses.

The Jellyfin metadata would certainly be a fit but what about streaming video content i.e. sequential reads of large files with random access?

For those who are unaware, there is another project [1] that tracks upstream which adds support for various codecs like Zstandard. Many folks (such as myself) opt to install their releases instead.

[1]: https://github.com/mcmilk/7-Zip-zstd

macOS I found to be particularly challenging to support because of insufficient Apple documentation, so hopefully this helps folks.

It's only marked as a draft because there has not been a PR to update the status as it was just approved this morning.

PEP 751: https://peps.python.org/pep-0751/

A long-standing issue with that was just recently fixed: https://github.com/rust-lang/rust/pull/133250

Hatchling maintainer here :)

What limitations have you personally experienced?

The effort is slower then what one would desire because we are all volunteers.

> My experiments suggest that about a quarter of this could be eliminated simply by enabling and then mandating the use of LZMA (XZ) compression for sdists and wheels (which currently must both use ordinary Gzip compression).

That won't happen as there is a slow effort behind the scenes to get Zstandard in the standard library, which is far better.

Workspaces is unblocked now, it depended on a large refactor which has now been merged: https://github.com/pypa/hatch/pull/1602

In my free time, it's the only thing I'm working on!

I think you're thinking of UV, this is a project that they adopted. As far as I understand UV is where development is happening and actually Rye is soft deprecated.

Very interesting; I'm quite excited for these future performance improvements! In small-medium sized projects the time isn't very noticeable but larger projects definitely are noticeable in CI.

edit: I should say for larger test suites rather than the project itself, but larger projects do tend to have larger test suites.

Did you report the issue to Hatch? I'd like to fix any bugs :)

edit: found it https://github.com/pypa/hatch/pull/1317, already fixed

Yes that feature will be coming right after PyCon! I just have too much to do right now between work, preparing for my talk and getting the next minor release out.

Sorry but what you're saying simply is not true from my experience. The potential of this technology is the ability to perform multiple actions simultaneously e.g. having your character strafe while zooming in while firing a trigger. With eye tracking you are limited to (for the most part) one action at a time, which is what I do now.

You are correct in that one could add more inputs but that only works if you can use the inputs. The individual in the video has full control of his head which many people do not. All I can do, for example, is use like two fingers.