Does this mean we might see an industry shift to RISC-V?

Early Arduino were all AVR 8-bit, at the time it was already on the way out. There were no shifts in industry to those chips.

People who got Arduino, either:

- blinked some LEDs and forgotten about it

- switched to esp32 and/or stm32

  - esp32 and esp8266 move is funny because people started buying esp8266 to add Wi-Fi to their arduinos and then realized that they can just throw away arduino all together.

 - switched to cheap clones that offer more
  
   - quick connect for that not only want to blink LEDs, but also have some cool graphs to look at (like temperature and humidity)

   - boards that specifically designed for their use case (i.e. battery and eInk connectors and circuitry required)

Arduino is inconsequential to industry as whole or even to hobbyist using it.

Time for a large industry shift to RISC-V?

I knew XSLT was just a passing fad...it only took 30 years of my career for it to pass...lol.

Regarding the turbofan and [0], above...if you're communicating to a non-engineer (me), how does the design get to the point of such complexity? I would love to learn the design story behind such an incredibly complex piece of machinery.

I am being serious, if you cannot tell.

For the same thrust it's more efficient to accelerate a large mass of air a small amount than t accelerate a small mass of air a large amount. The fan is what gives you that.

I rough guessed the cost of fuel over a 737's life as $150 million. Where the engines cost something around $30 million. That pushes the engineering economics towards maximizing the engines efficiency.

I'm suspicious that bypass ratio's for turbofans are close to maxed out. The diameter of the fan gets unwieldy. That was the design issue that the 737 Max was trying to get around. With bad results. Possible the future is hybrid designs with two engines and 4 or more electrically driven fans.

Two words: LED clocks.

I'm no linguist, but the question does seem unambiguous, or quite clear, to a reasonable observer. The context is "voting in a US election" AND the subject is "an illegal immigrant" WITH an assumption that the illegal immigrant has, in fact, illegally emigrated to the US.

Above anything, this shows the performance gains from 3.10 -> 3.11:

  >> python3.10 create_task_overhead.py
  100,000 tasks   185,694 tasks per/s
  200,000 tasks   165,581 tasks per/s
  300,000 tasks   170,857 tasks per/s
  400,000 tasks   159,081 tasks per/s
  500,000 tasks   162,640 tasks per/s
  600,000 tasks   158,779 tasks per/s
  700,000 tasks   161,779 tasks per/s
  800,000 tasks   179,965 tasks per/s
  900,000 tasks   160,913 tasks per/s
  1,000,000 tasks  162,767 tasks per/s

  >> python3.11 create_task_overhead.py
  100,000 tasks   289,318 tasks per/s
  200,000 tasks   265,293 tasks per/s
  300,000 tasks   266,011 tasks per/s
  400,000 tasks   259,821 tasks per/s
  500,000 tasks   251,819 tasks per/s
  600,000 tasks   267,441 tasks per/s
  700,000 tasks   251,789 tasks per/s
  800,000 tasks   254,303 tasks per/s
  900,000 tasks   249,894 tasks per/s
  1,000,000 tasks  266,581 tasks per/s

Python 3.11 running in a-Shell on an M1 iPad Pro

    Python 3.11.0 (heads/3.11-dirty:8d3dd5b9647, Dec  7 2022, 08:17:48) [Clang 14.0.0 (clang-1400.0.29.202)]
 on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 
    [~/Documents]$ python test.py
    100,000 tasks    127,992 tasks per/s
    200,000 tasks    115,960 tasks per/s
    300,000 tasks    117,205 tasks per/s
    400,000 tasks    113,131 tasks per/s
    500,000 tasks    109,609 tasks per/s
    600,000 tasks    116,649 tasks per/s
    700,000 tasks    110,743 tasks per/s
    800,000 tasks    111,361 tasks per/s
    900,000 tasks    109,688 tasks per/s
    1,000,000 tasks          117,064 tasks per/s

Ubuntu:

  100,000 tasks   155,257 tasks per/s
  200,000 tasks   138,569 tasks per/s
  300,000 tasks   134,779 tasks per/s
  400,000 tasks   144,371 tasks per/s
  500,000 tasks   135,672 tasks per/s
  600,000 tasks   135,299 tasks per/s
  700,000 tasks   146,456 tasks per/s
  800,000 tasks   139,192 tasks per/s

Windows SB3:

  100,000 tasks    177,778 tasks per/s
  200,000 tasks    150,588 tasks per/s
  300,000 tasks    152,381 tasks per/s
  400,000 tasks    134,031 tasks per/s
  500,000 tasks    160,804 tasks per/s
  600,000 tasks    129,293 tasks per/s

M2 Macbook Pro 16GB 16-inch 2023

100,000 tasks 184,167 tasks per/s

200,000 tasks 160,964 tasks per/s

300,000 tasks 165,278 tasks per/s

400,000 tasks 149,577 tasks per/s

500,000 tasks 160,593 tasks per/s

600,000 tasks 168,098 tasks per/s

700,000 tasks 161,837 tasks per/s

800,000 tasks 160,364 tasks per/s

900,000 tasks 149,479 tasks per/s

1,000,000 tasks 155,919 tasks per/s

Make sure you set your cpu frequency governor to "performance".

If your Linux machine is working an order of magnitude slower than you'd expect from the hardware, that's the first thing I'd check.

I love that you include the BNF-ish grammar. Grammars are so straight-forward to read, I wish my eyes didn't glaze over during those times I've tried to sit down and create one.

Adding the snake case does move it more to the Python idioms, for sure.