He was no Rafael, but look at this piece, could have been a banger punk rock cover!

I appreciate the idea, but the picture is good enough for me, thanks for that!

Oh, wow! Thanks for noting!

Basically ‘class Parser[T]: pass’ is same as what used to be (from memory):

from typing import Generic, TypeVar
T = TypeVar(“T”)
class Parser(Generic(T)): pass

Like, what language is this?

I have a contrarian urge to reply "that's just easy!", which it's not; however, here's a bunch of techniques that I found very helpful:

keleshev.com/advanced-err...

But it relies on polymorphic variants, which is an OCaml-only feature, as far as I know.

How to reconcile that the standard says:

prog [-xyz] == prog [-x] [-y] [-z]
prog [options] == prog [-x] [-y] [-z]

but at the same time,

prog [<x> <y>] != prog [<x>] [<y>]

Found this counter-example from the standard:

cal [[] ]

(which is clearly not the same as [] [])

pubs.opengroup.org/onlinepubs/9...

My only problem that makes me keep returning to this is that in EBNF the square brackets don't work this way ([<x> <y>] != [<x>] [<y>]), and the POSIX utility convention notation is clearly inspired by EBNF…

Then there's the `[options]` shortcut. If we assume that the `options` from the options shortcut stands for all the options in the `Options:` section, then the original behavior also makes more sense:

[options] => [-x -y -z] => [-x] [-y] [-z]

But maybe the right way is to say that this is only the case for these short option strides, and not for anything else?

[-xyz] => [-x] [-y] [-z]
[-x -y -z] => [(-x -y -z)]

That's because the POSIX standard has examples like `prog [-xyz]` where it is clear that this means the same as `prog [-x] [-y] [-z]`.

Exactly. At my desk I have two USB-C connectors, one for Raspberry Pi, and another one for laptops, and it doesn't work if you plug in the wrong one.

My LG monitor (32UN880-B) is advertised at 60W PD, but at 5V it gives my Pi 400 low voltage warnings and crashes at high loads.

Another BenQ monitor I have (PD3205U) advertises 90W PD and works just fine powering Pi 400.

Pi 5 and Pi 500 require 27W at 5V, and almost certainly no device will provide that via USB-C other than the official power supply.

Everyone know shat 3840 × 2160 divided by two gives 1920 × 1080, but did you know that 3840 × 2160 divided by *three* gives 1280 × 720!

So, 720p looks crisp (but pixelated) on 4K, but horribly scaled on an 1080p panel.

Pinebook Pro has a 1080p panel, and downscaling looks horrible. On the other hand, Pi 400 used with 4K monitor can be downscaled, to 1080p or 720p without scaling issues.

Originally my plan was to get two Pinebook Pro for kids. I got one to test out, but could not get Minecraft running with a good frame rate (neither Bedrock, nor Java).

Of course, ever since Pi 400 came out it was obvious that there will be a Raspberry Pi laptop at some point in time, and the new Raspberry Pi screen is also an obvious stepping stone to that, but it's surprising how long it takes, considering what PINE64 folks done with Pinebook Pro long ago.