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.

ADHD is also very strongly linked to cigarette smoking, by the way. What I mean is that nicotine is a form of self-medication

True. Honestly they should have taken the second bet in the 2010s and come up with a clean sheet 737 successor. It would have been bold, but the company would have been in far better shape today

I am a bit surprised by the negativity here. Python's ecosystem fragmentation is legendary at this point, and it's lack of portability is well known. Let's face it - a lot of the "ML" applications for the next decade are going to be boring, but super important applications. Stuff like self-driving labs, process modules in factories and so on.

And the idea that you will do everything with a conda package at every point is laughable. You need a compilable language, where code can be ported over from Python very rapidly, and where ML/AI tools such as differentiability is a first class citizen. That language doesn't really exist today, but multiple billions of actual industrial applications need it.

In fact, what the negativity shows here is how skewed Hacker News is towards the bit folks, and how little they talk to the atoms side of things.