Why not? I maintain markdown files explaining everything (this is committed). Also the Python code is typed and has detailed numpydoc docstrings.

Not true. The CdA (coefficient of drag multiplied by frontal area) matters far more for range than the weight for range. That is a smaller EV, which may very well be heavier can have a higher range and efficiency.

The Cd matters for highway driving, but weight is the dominating factor for city driving.

As efficiency improves across motors and inverters, wouldn't regen make CoD matter more, possibly tilting it to the dominant factor again?

Regen recoups about 80% of the kinetic energy, and it is already up close to the theoretical physical limit without switching to exotic materials.

Cd will never be the dominating factor at speeds which do not produce significant aerodynamic drag.

> Cd will never be the dominating factor at speeds which do not produce significant aerodynamic drag

That helped it sink in, thank you

Remember also that tires (deformation) and the like sap energy too

I don’t think there’s a whole lot of room for improvement there.

There are a lot of errors in that article. Like line 1, the idea that foreign students get jobs before Americans do. Quite the opposite in real life. Go to any school, and see the employment rates in that school for US vs foreign students.

Also H1B pays FICA taxes, that exemption is only for OPT. The OPT exemption can be easily removed.

That first point is not comparing students, it is saying that the H1B visas issued that year all have jobs lined up (which is a requirement of the visa). Those jobs are what the new graduates would normally be competing for.

And you have to apply to get that job. And the vast majority of companies would prefer a US citizen or an LPR for that job, because there is no guarantee that you will get the visa approved.

Grad students (foreign and non-foreign) also don't pay FICA (or at least, they didn't when I was in grad school). Not that it matters much, grad student pay is nothing to dream about.

I use LLMs for generating documentation- I write my code, and ask Claude to write my documentation

I think you are doing it the wrong way around.

Maybe not. I trust Claude to write docs. I don’t trust it to write my code the way I want.

I have a problem with Python's `Optional` type. For example for this following code:

   from typing import Optional, Union
   def square(
      a: Union[int, float], 
      b: Optional[int] = 2
   ) -> float:
      c = a**b
      return c

Many type checkers throw an error because `Optional[int]` actually means `int | None` and you cannot square an `int` or a `float` with a `None`. Is there any plans for *ty* around this?

I think that's a genuine error, since as you say, `None` is a possible value for `b` according to your signature.

To handle this you would need to use "narrowing" to separately handle the case where `b` is `None`, and the case where it is not:

  def square(a: Union[int, float], b: Optional[int] = 2) -> float:
      if b is None:
          return 0
      else:
          c = a**b
          return c

https://play.ty.dev/97fe4a09-d988-4cc3-9937-8822e292f8d1

(This is not specific to ty, that narrowing check should work in most Python type checkers.)

I used to use conda, but have switched entirely to uv now

As someone new to Python: what was ever the appeal of conda that uv doesn't satisfy?

conda doesn't just package python libraries, but also the C/Fortran/other bits that the scipy stack often depended on. With the rise of binary wheels that is less needed though

Fundamentally it is a fresh usr/bin per environment with all that can go into that. Not just python tooling. R packages. Binaries. All of that. Env can be exported as a yaml file and trivially shared without appending some header to all scripts you write.

I think it's more about tool X vs Y, but about ecosystems and packaging approaches; in other words Python packaging (which has tools like pip, uv or poetry) vs conda packaging (which has tools like conda itself, mamba or pixi). https://pypackaging-native.github.io/ is an excellent starting point to learn about the limitations on Python packaging for native dependencies and compiled extensions.

Distributing non Python packages via the same channel that Python packages may depend on. E.g, h5py depending on libhdf5.

As someone using Python from 2017, there was no uv then, and conda worked fine but was glacially slow.

I think TypeGuard (https://github.com/agronholm/typeguard) also does runtime type checking. I use beartype BTW.

pycontracts: https://github.com/AlexandruBurlacu/pycontracts

icontract: https://github.com/Parquery/icontract

The DbC Design-by-Contract patterns supported by icontract probably have code quality returns beyond saving work.

Safety critical coding guidelines specify that there must be runtime type and value checks at the top of every function.

I use TypeGuard too, but only in local dev and pytest runs. I find it really useful so I'm now intrigued to try Beartype too. I found the readme on GitHub confusing at a glance though, I need decorators to type check something?

My one issue with uv is that uv publish does not still have a —skip-existing flag like twine has.

I am more and more convinced that type checked Python is not always the best idea. The people who are the most virulently pro type checking in Python are not data science folks.

Python's type ecosystem's support for proper type checked data science libraries is abysmal (`nptyping` is pretty much the most feature complete, and it too is far from complete), and has tons of weird bugs.

The Array API standard (https://data-apis.org/array-api/latest/purpose_and_scope.htm...) is a step in the right direction, but until that work is close to some sort of beta version, data science folks will have tons of type errors in their code, in spite of trying their best.