notatallshaw

6 ms·

31.
by notatallshaw 1y ago
A lot of the tools you list here are composable, mypy checks type hints, black formats code, because of the purpose and design ethos of those two tools they would never think to merge. So which is it that you want, to just reach for one too
32.
by notatallshaw 1y ago
> Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't: > …where is it even puling "tuple[Any]" from… Perhaps it's a bug in pyrefly, perhaps
33.
by notatallshaw 1y ago
> There is one part of Python that I consider a design flaw when it comes to packaging: the sys.modules global dictionary means it's not at all easy in Python to install two versions of the same package at the same time. This makes
34.
by notatallshaw 1y ago
The standard library does not directly include type hints, they are stored in typeshed: https://github.com/python/typeshed You can take a look yourself if you think some of them are wrong: https://github.com
35.
by notatallshaw 1y ago
> There is, the web. The web distributes code directly to end users at a much larger scale. To distribute the bandwidth costs, the web is federated: to depend on a script you refer to its url, and whoever hosts this url foots the bill. B
36.
by notatallshaw 1y ago
Taking PyPI as a central place of packages, it is known that their bandwidth bill would be $1.8+M per month ( https://dustingram.com/articles/2021/04/14/powering-the-pyth... ) were it not for Fastly giving
37.
by notatallshaw 1y ago
Seems like this is a fairly recent change, for Pnpm at least, https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts... What has been the community reaction? Has allowing scripts been scalable for users? Or could
38.
by notatallshaw 1y ago
> Obstinate maintainership is a real failure mode of open source I agree, but I also think sometimes that people think it's obstinate maintainership and it's not. For example, large PRs are hard to merge from a contributor who
39.
by notatallshaw 1y ago
> I guess you're talking about the fact that uv's cache only stores the unpacked version, rather than the original wheel? I'm planning to keep the wheel around, too. But my point was more that because of this cache structu
40.
by notatallshaw 1y ago
> No. This something people tell each other, that it's a lack of resources, Well uv, as an OSS project, has come along with around 2 orders of magnitude more manpower than pip and has solved a lot of problems > but in reality alm
41.
by notatallshaw 1y ago
> However, pip has some really gnarly internal infrastructure that prevents it from taking advantage of a lot of uv's good ideas (which in turn are not all original). FWIW, as a pip maintainer, I don't strongly agree with this
42.
by notatallshaw 1y ago
> easy_install I don't know what guides you're reading but I haven't touched easy_install in at least a decade. It's successor, pip, had effectively replaced all use cases for it by around 2010.
43.
by notatallshaw 1y ago
Well it was just a guess, "GPU-aware" is a bit mysterious to those of us on the outside ;).
44.
by notatallshaw 1y ago
Package names and module names are not coupled to each other. You could have package name like "company-foo" and import it as "foo" or "bar" or anything else. But you can if you want have a non-flat namespace f
45.
by notatallshaw 1y ago
Given Astral's heavy involvement in the wheelnext project I suspect this index is an early adopter of Wheel Variants which are an attempt to solve the problems of CUDA (and that entire class of problems not just CUDA specifically) in a
46.
by notatallshaw 1y ago
Probably the more useful blog post: https://astral.sh/blog/introducing-pyx
47.
by notatallshaw 1y ago
> uv pip install --system torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 uv has a feature to get the correct version of torch based on your available cuda (and some non-cuda) dri
48.
by notatallshaw 1y ago
setdefault was a go to method before defaultdict was added to the collections module in Python 2.5, which replaced the biggest use case.
49.
by notatallshaw 1y ago
> is cheap It's not even cheap, it's just possible to get companies to donate the resources to sustain it: https://dustingram.com/articles/2021/04/14/powering-the-pyth... What it is is fea
50.
by notatallshaw 1y ago
> that's like suggesting someone complaining about security issues should fork libxml or openssl because the original developers don't have enough resources to maintain their work. I disagree with this analogy, both those libra
51.
by notatallshaw 1y ago
If you want to offer a PyPI competitor where your value is all packages are vetted or reviewed nothing stops you, the API that Python package installer tools to interact with PyPI is specified: https://packaging.python.org/e
52.
by notatallshaw 1y ago
> recursive self-improvement. What LLM is recursively self-improving? I thought, to date, all LLM improvements come from the hundreds of billions of dollars of investment and the millions of software engineer hours spent on better traini
53.
by notatallshaw 1y ago
Two years ago was Python 3.11, my real world workloads did see a ~15-20% improvement in performance with that release. I don't remember the Faster CPython Team claiming JIT with a >50% speedup should have happened two years ago, can
54.
by notatallshaw 1y ago
Astral's focus has been to support the simplest use case, pure Python project with a standard layout. Their aim has been that most users, and especially beginners, should be able to use it with zero configuration. As such they do not c
55.
by notatallshaw 1y ago
What people like about this workflow is that you're not maintaining a separate venv or a separate requirement and it's declarative rather than imperative, this gives you two big advantages: First, you can move that script to a dif
56.
by notatallshaw 1y ago
It looks like TikToken is written in Rust ( https://github.com/openai/tiktoken/tree/main/src ), are the gains here actually from porting to C++?
57.
by notatallshaw 1y ago
> You're trying to shove a square peg into a round hole Yeah, that's literally the point of my Reddit post
58.
by notatallshaw 1y ago
And yet, some Python users insistent on type hinting very dynamic Python code while trying to keep how dynamic it is.
59.
by notatallshaw 1y ago
> Don't write functions that support hundreds of input data types But by it's nature, duck typing supports an unbounded number of input types and is what Python was built on. You've already decided duck typing is wrong and
60.
by notatallshaw 1y ago
As the author of that post, I'd like to point out the example was meant to be stupid. The purpose was to show different ideologies and expectations on the same code don't work, such as strict backwards compatibilities, duck typing

More ›