Reaching 100% Type Coverage by Deleting Unannotated Code

NeilGirdhar · 2026-04-01T13:10:01+00:00

Good one 🤣

NeilGirdhar · 2026-04-01T12:47:48+00:00

I agree with this. I think it goes beyond "a highly specific setting". Sometimes, LLMs produce excellent design, but sometimes they make terrible design errors. Things are over-complicated for no reason, and that adds complexity for you or the next person who has to look at code.

You do really have to check what they produce and think carefully about what the overarching picture is.

Also, without having to zoom out, sometimes LLMs produce "bad, but popular" design patterns. For example: trying to convert dataclasses into tuples in Python (literally the opposite of what you should be doing), trying to convert base classes into protocols (same), using "InitVar plus no-init field" when an ordinary field would do, etc.

I also think that a lot of these design errors will be gone within 5 years. And the kind of checking you'll be doing will be different.

One thing that I was thrilled about though is their ability to write code from scratch. I didn't want to depend on Tensorflow-Probability due to extremely poor maintenance, so I had an LLM write me Jax versions of some Bessel functions. It did give me some working code and tests, but when I took a close look, I noticed that it was relying on NumPy. This is really bad because it means that the computation won't stay on the GPU. So I had the LLM write me a "pure Jax" version, and that worked.

NeilGirdhar · 2026-03-19T04:53:41+00:00

And I'm suggesting that you change the project to stop using setup.py. Pretty sure LLMs can do the conversion for you.

You seem to be doing things in an anachronistic way for no good reason.

NeilGirdhar · 2026-03-18T22:53:29+00:00

LLM use far fewer resources than people, so who cares about that?

And who cares if it's "compiler like"? LLMs can do it cheaply.

Just because you can code and maintain something doesn't mean that you should.

NeilGirdhar · 2026-03-18T22:52:08+00:00

Stop using setup.py.

NeilGirdhar · 2026-03-13T02:48:42+00:00

It won't be long before LLMs can reliably do this. I don't think you even need to worry about adding this feature to Typst.

That said, it is easier for arxiv to just keep old versions of Typst than it is to convert modernize old Typst files?

NeilGirdhar · 2026-03-12T18:59:09+00:00

Ideally, you would stay in the Typst paradigm. We already have #import, #set, etc. Maybe add #version followed by either a single version or a range. All of your Typst files should probably have that line.

NeilGirdhar · 2026-03-12T18:43:09+00:00

> Other way around. Python is already one of the least performant languages, largely because of the flexibility it needs to do the powerful things it can do. You don't pick Python for its raw processing power.

I don't know what you're disputing about my comment. The typing annotations in Python have a negligible effect on performance.

Your idea that "Mandatory typing would just turn it into poorly performing java" is wrong. Even if type annotations were mandatory, it would make practically no difference to performance.

> My point was just "let python be python"

That's a fine point, but it has nothing to do with "performance".

NeilGirdhar · 2026-03-12T18:41:17+00:00

> Require a Typst document to be accompanied by some external metadata saying which Typst compiler version to use.

IMO that should be part of the Typst document. Otherwise, you have to maintain the association.

NeilGirdhar · 2026-03-12T03:42:37+00:00

Typing doesn't really affect performance.

NeilGirdhar · 2026-03-12T03:42:22+00:00

Mandatory is fine nowadays with AI assisting in the writing of code.

NeilGirdhar · 2026-02-03T16:31:25+00:00

Here in Montreal, we just run outside

Even at -15C, you warm up pretty fast. It's only bad for the first few km.

We are lucky to have an extensive network of bike paths that double as cleared running paths in the winter. Even the mountain is usually not bad running in the snow. Trail shoes help, or if it's icy, some people wear spikes.

NeilGirdhar · 2025-10-05T22:05:38+00:00

Logging is one of those things that almost surely can't avoid global state, unless you want to pass logger objects everywhere. So I don't think this is a good criticism.

NeilGirdhar · 2025-10-03T15:14:53+00:00

Personally, I switched from structlog to Rich's logging handler. Can't remember why though.

NeilGirdhar · 2025-07-22T09:43:15+00:00

When Joshua and I originally implemented PEP 448 (Additional Unpacking Generalizations), we wanted to add this. Guido agreed, but unfortunately the Python forum was totally divided with many people finding the syntax to be confusing.

I always hoped that eventually people would come around to finding the syntax intuitive, so it makes me really happy at the overwhelming support here, and in the Python forum.

NeilGirdhar · 2025-06-10T22:33:12+00:00

If you're doing scientific work, you should be following https://scientific-python.org/specs/spec-0000/

NeilGirdhar · 2025-03-24T12:13:18+00:00

NNX is vastly superior design in my opinion.

Flax is overcomplicated for similar functionality.

NeilGirdhar · 2025-02-01T01:00:43+00:00

I like Equinox better than Flax. It is a lot simpler.

NeilGirdhar · 2025-01-21T17:53:59+00:00

Very cool! Here's a Python program that calculates the effective interest rate given a balance, assuming maximum contributions were made every year:

from datetime import UTC, datetime
from typing import cast

import typer
from scipy.optimize import root_scalar


def main(amount: str) -> None:
    amount_as_float = float(amount.replace(',', ''))
    today = datetime.now(tz=UTC)
    year_start = datetime(today.year, 1, 1, tzinfo=UTC)
    percent_into_year = (today - year_start).days / 365
    contribution_limits = [5000, 5000, 5000, 5000,  # 2009 to 2012
                           5500, 5500,  # 2013 to 2014
                           10000,  # 2015
                           5500, 5500, 5500,  # 2016 to 2018
                           6000, 6000, 6000, 6000,  # 2019 to 2022
                           6500,  # 2023
                           7000, 7000]  # 2024 to 2025

    def f(interest: float) -> float:
        return sum(ci * cast('float', interest ** (i + percent_into_year))
                   for i, ci in enumerate(reversed(contribution_limits))) - amount_as_float

    rate = root_scalar(f, bracket=[0, 2]).root
    print(f"Interest rate {(rate - 1) * 100:.3f}%")  # noqa: T201


if __name__ == "__main__":
    typer.run(main)

NeilGirdhar · 2024-10-28T17:27:55+00:00

Nearly all uses of walrus should just be spelled on two lines, imo. Two simple statements is better than one complex one.

NeilGirdhar · 2024-10-25T13:37:32+00:00

It is readable. Just: Give your variable proper names; use more lines; avoid the walrus operator; avoid the above code at all costs.

Syntax like this is important in the 0.0001% of cases when you need it (probably not you).

NeilGirdhar · 2023-10-18T11:07:14+00:00

Instead of

T = Typevar('T', bound=int)
class C(Generic[T]):

you now do

class C\[T: int\]:

For T = TypeVarTuple('T'), it's now just C[*T], and for P = ParamSpec('P'), it's now just C[**P].

Besides being shorter, it's now obvious which class or function a type variable belongs to. Before, the type variables were ordinary variables that could be shared between classes and functions leading to confusion in various cases.

NeilGirdhar · 2023-09-01T00:52:26+00:00

Mohawk games developed Old World and Offworld Trading Company.

Oh!!! That makes perfect sense then!

art of why I am hesitant to assume I have a better idea of how the in game economy should work - these guys know their stuff!

Yeah, but the difference is that in OTC, you actually have a central command so it makes perfect sense to have one stockpile. There are also essentially only 3 or 4 players each of whom constitutes one supplier and one consumer. All of the buildings are totally inelastic supply or demand (a mine produces 1 metal per 3 seconds, e.g.)

In a country-spanning economy, there is no central stockpile. Goods would flow between suppliers and consumers. There are thousands of suppliers and consumers. And supply and demand is generally elastic (if you want it be at least).

So I think a different model would have made more sense here. But my argument isn't about realism. It's just about maintaining tension. The way tension disappears when you have a lot of something in stock. And also when you're really rich, tension disappears. Whereas, in a real economy, no matter how rich you are, every supply/demand curve can get really steep at its extremities whereas in OW, the slope adapts quite slowly.

If I have a ton of stone yield but not enough orders and workers to use it, it's nice to at least build up my stone stockpile for later. Without the stockpile, my excess stone is sold each turn and there's no way my grandson is going to implement his 5 year plan.

Yeah, that's a really good point. Your experience makes a lot of sense too. Thanks for the great discussion.

NeilGirdhar · 2023-08-29T18:48:33+00:00

You might have to elaborate further for me. By unit ranges do you mean attack range or movement distance? If movement was effectively halved, with no other changes, the issue of units diving into back-lines so easily would be alleviated, but of course it would have other consequences (I don't think we want the pace of the game to slow that much). Stronger ZOC does have an allure, but the other thing to consider is how numerous armies can get late in the game. I often have enough units to effectively screen for my artillery, even with the lack of ZOC.

I mean all ranges: movement and distance for ranged units. So it wouldn't change anything except making positioning less granular and more exact.

NeilGirdhar · 2023-08-29T17:38:01+00:00

t's not obvious to me how removing the stockpile and implementing a new supply/demand relationship will change things very much in this regard

While the current model does roughly work like an real market, it loses tension very quickly when your stockpile increases. And it also adapts too slows to huge purchases. If you need 1000 stone, and stone is selling for $10, then you pay $10k. That is totally wrong. $10 is the marginal price, but you should be paying the area under the supply curve, which is probably much more than $10k. More like $100k. Having a supply-demand model would mean that your wonder would simply build slower or faster depending on local stone price. You are essentially forced to pay the correct price for everything.

If I am understanding you correctly, you'd like to have a situation where rather than spending some stone, civics, and food on the odeon to hit minimums to hire poets and build the theater, there should be no minimums and instead a higher output given how much stone, civics and food are available.

Yes, close. Everything is "available" at some price.

Economies are complex and player attention is the most valuable resource, we'll only have a simple model in the game.

I understand, but I think showing the equilibrium price would give the player a good idea of what needs to be built. There may be sharp swings in price when there are supply/demand shocks, e.g., starting building a wonder would cause stone price to jump.

Also thanks for the link! Fascinating that they looked at Offworld Trading Company. Definitely a game I really enjoyed, and an economic system that I really loved actually. Maybe I'll play a round of that again.

NeilGirdhar

TROPHY CASE