> I realize this all probably sounds very silly to someone born before 1980

I was born after 1980 and I think you're beating a dead horse, here. You're conflating accessibility with convenience. Not just with this comment, but others you've made in this thread.

> those goddamn BIC pens all go bad (ink dries up or something), before I use even 5% of one of them.

Grab the pen by the end opposite the nib, give it a good shake for a few seconds, lick the nib, scribble on a scrap piece of paper until it starts writing again. Problem solved. You can't resurrect a dead laptop or computer by licking and shaking it (at least I've never succeeded in doing so).

Editting simcity saves was my introduction to hex editing...

For me, iirc, it was Bard's Tale

> And I'd rather keep the library warning free instead of telling the users to switch warnings off.

Thank you! Separately, but related: fuck you, Google! (every time I have to deal with protobuf in C++, I curse Google and their "we don't give a shit about signed vs unsigned comparisons").

And I don't think there's an excuse not to. I work on giant projects with tons of people, that still manage to use -Werror.

Yeah, some warnings are turned off, but not as many as you'd think, and usually for good reasons, which also includes deliberate design decisions. For example, we don't care about pre-C11 compatibility (because we won't build for pre-C11), so that warning is off. We also like 0-sized arrays, so that warning is off as well.

It's a moving target, because compiler engineers add new warnings over time. Adapting the new compiler means taking care of the new warnings. There's almost always a way to do so instead of turning a new warning off.

The person who writes the library isn't using the same compiler as you.

True, so?

So turn on -Werror in your CI builds, but don't turn it on for all builds.

I mean, yeah, obviously that a)only works when we build our projects ourselves, and b) for external libraries you have less control over that.

Fuck projects that ship conpile scripts with -Werror.

I don't understand this discussion. What I said was that for our big projects internally, we keep them warning-free, and -Werror obviously helps tremendously with that. Nobody said you need to ship externally with -Werror, or anything about external libraries the project may be using.

By keeping your own project warning-free in your environment, you are doing a service to everyone.

Sounds like you are doing the right thing (-Werror internally, not externally). So this discussion is probably just based on a miscommunication. Happens pretty often on HN unfortunately.

I just turn warnings off for protobuf stuff. In general I do that for any code I don't own but have to compile.

3rdparty libs should be treated as -isystem. Otherwise you're just needlessly paying for other's mistakes.

The problem is: it's infectious into the generated code, as well. Is that 3rd party or not? Yes, it was generated by a 3rd party tool, but from, ostensibly, _your_ protobuf file.

edit to add: and yes `-isystem` is absolutely a useful tool. If memory serves, though, it doesn't protect from macro or template expansions, though.

Hey, at least Python is nowhere near Perl in terms of language creep. I don't need a Period Table of Operators [0] to keep Python straight in my head.

[0] https://www.ozonehouse.com/mark/periodic/

> The reason it works is because Python functionally has no bool type. True and False are just integers with names.

This has not been true since around 2.4 or 2.5. The oldest Python I have available to me currently is 2.7, and this holds then, as it does now in 3.13:

    >>> type(True)
    <class 'bool'>
    >>> type(1)
    <class 'int'>

Prior to having a bool type, Python didn't even have True/False keywords.

The reason something silly like `4 + True` works is because the bool type implements `tp_as_number` [0]. The reason it works this way is intentional because it would been a Python 3 str-style debacle if ints and bools were not interchangeable.

[0] https://github.com/python/cpython/blob/main/Objects/boolobje...

> Meanwhile there is another reason why the number of government workers has gone down:

Uh...excluding the very recent cuts this year under Trump; the number of civilians in the US Federal work force has gone up fairly steadily. [0]

We had 23.592 million civilian employees in Jan 2025. 21.779M in Jan 2021, after being largely stagnant overall the previous 10 years. That's a net change in excess of 1.8M employees under Biden.

I do find it interesting that it appears that employee count was flat, or even down under Obama, but until COVID, there was a steady increase under Trump v1.

[0] https://fred.stlouisfed.org/series/USGOVT

> the number of civilians in the US Federal work force has gone up fairly steadily.

The graph you provided is not Federal government, it’s all US government which includes state & city, and other types of government employees. It should be expected this grows with population size, and to get a sense of whether it’s really shrinking or growing, you should divide by population. But in any case, this chart doesn’t backup your claim that Federal government is growing.

The link to the Federal government was just underneath that graph: https://fred.stlouisfed.org/series/CES9091000001. US Federal government absolute size peaked in 1991 and has gone down slightly since then. If you divide this one by population, the decline would be a bit stronger and more obvious. The ~10 year spikes are census workers. Notice we can see the peak in 1991 with or without the census spikes.

And beside government institutions there are lots of institutions at state and city level.

Institutions at the state and city level are called “government”, and those are included in the data parent linked to.

> because the simulator had a bug

I had something similar happen when I was taking microcomputers (a HW/SW codesign class at my school). We had hand-built (as in everything was wire wrapped) 68k computers we were using and could only download our code over a 1200-baud serial line. Needless to say, it was slow as hell, even for the day (early 2000s). So, we used a 68k emulator to do most of our development work and testing.

Late one night (it was seriously like 1 or 2 am), our prof happened by the lab as we were working and asked to see how it was going. I was project lead and had been keeping him apprised and was confident we were almost complete. After waiting the 20 minutes to download our code (it was seriously only a couple dozen kb of code), it immediately failed, yet we could show it worked on the simulator. We single-stepped through the code (the only "debugger" we had available was a toggle switch for the clock and an LED hex readout of the 16-bit data bus). I had spent enough time staring at the bus over the course of the semester that I'd gotten quite good at decoding the instructions in my head. I immediately saw that we were doing a word-compare (16-bit) instead of a long-compare (32-bit) on an address. The simulator treated all address compares are 32-bit, regardless of the actual instruction. The real hardware, of course, did not. It was a simple fix. Literally one-bit. Did it in-memory on the computer instead of going through the 20-minute download again. Everything magically worked. Professor was impressed, too.

> Which is redundant for most functions as they only have positional parameters.

Huh? This is not true.

    def foo(a, b, c): ...

This can be invoked as either `foo(1, 2, 3)` or `foo(c=3, b=2, a=1)`:

    >>> def foo(a, b, c):
    ...     print(f"{a=}")
    ...     print(f"{b=}")
    ...     print(f"{c=}")
    ...
    >>> foo(1, 2, 3)
    a=1
    b=2
    c=3
    >>> foo(c=3, b=2, a=1)
    a=1
    b=2
    c=3
    >>>

    Help on built-in function sin in module math:

    sin(x, /)
        Return the sine of x (measured in radians).

   
   >>> math.sin(x=2)
    ~~~~~~~~^^^^^
      TypeError: math.sin() takes no keyword arguments

/ is used everwhere and it's usually just noise. Unexplained noise.

It is often used for builtins, because emulating the default Python behaviour of accepting arguments both by position and by name is a pain with the Python/C API. (There are other use cases for positional-only arguments, such as accepting an arbitrary function and an arbitrary set of arguments to call it with at the same time—for example, to invoke it in a new coroutine—but they are pretty rare.) This pecularity of most builtin functions has been there since before Python 3 was a thing, it’s just been undocumented and difficult to emulate in Python before this syntax was introduced.

As for unexplained noise—well, all other parts of the function declaration syntax aren’t explained either. You’re expected to know the function declaration syntax in order to read help on individual function declarations; that’s what the syntax reference is for.

How would you discover the syntax reference via the repl help() system?

Found it.

>>> help('def')

A thought: maybe the pulse could be some sort of link status probing? e.g. "is this thing plugged in?"

Caveat: I have not looked at the neither the API nor the implementation of Kreuzberg, this is purely from personal work.

Even with CPU bound code in Python, there are valid reasons to be using async code. Recognizing that the code is CPU bound, it is possible to use thread and/or process pools to achieve a certain level of parallelism in Python. Threading won't buy you much in Python, until 3.13t, due to the GIL. Even with 3.12+ (with the GIL enabled), it's possible (but not trivial) to use threading with sub interpreters (that have their own, separate GIL). See PEP 734 [0].

I'm currently investigating the use of sub interpreters on a project at work where I'm now CPU bound. I already use multiprocessing & async elsewhere, but I am curious if PEP 734 is easier/faster/slower or even feasible for me. I haven't gotten as far as to actually run any code to compare (I need to refactor my code a bit with the idea of splitting the work up a bit differently to account for being CPU instead of just IO bound).

[0] https://peps.python.org/pep-0734/

Will it lock the GIL if you use thread executor with asyncio for a native c / ffi extension? If that’s the case, that would also add to benefits of asyncio.