Are you expected to run five Python type-checkers now?

GP's point is obvious: performance is immaterial to the discussion. Static code analysis is about preventing bugs. Therefore OP fails to make any sort of point, as it's a straw man argument.

There are times that I yearn for TS's ability to do duck type reasoning in e.g. Rust (despite that not being feasible) when working with very large data types.

I have lived in statically typed languages almost all of my life, and even when I don't, I pretend I do, just without having a typechecker. So I'm very curious about what I'm missing.

        sqlalchemy.orm.relationship(argument: _RelationshipArgumentType[Any] | None = None, secondary: _RelationshipSecondaryArgument | None = None, *, uselist: bool | None = None, collection_class: Type[Collection[Any]] | Callable[[], Collection[Any]] | None = None, primaryjoin: _RelationshipJoinConditionArgument | None = None, secondaryjoin: _RelationshipJoinConditionArgument | None = None, back_populates: _RelationshipBackPopulatesArgument | None = None, order_by: _ORMOrderByArgument = False, backref: ORMBackrefArgument | None = None, overlaps: str | None = None, post_update: bool = False, cascade: str = 'save-update, merge', viewonly: bool = False, init: _NoArg | bool = _NoArg.NO_ARG, repr: _NoArg | bool = _NoArg.NO_ARG, default: _NoArg | _T = _NoArg.NO_ARG, default_factory: _NoArg | Callable[[], _T] = _NoArg.NO_ARG, compare: _NoArg | bool = _NoArg.NO_ARG, kw_only: _NoArg | bool = _NoArg.NO_ARG, hash: _NoArg | bool | None = _NoArg.NO_ARG, lazy: _LazyLoadArgumentType = 'select', passive_deletes: Literal['all'] | bool = False, passive_updates: bool = True, active_history: bool = False, enable_typechecks: bool = True, foreign_keys: _ORMColCollectionArgument | None = None, remote_side: _ORMColCollectionArgument | None = None, join_depth: int | None = None, comparator_factory: Type[RelationshipProperty.Comparator[Any]] | None = None, single_parent: bool = False, innerjoin: bool = False, distinct_target_key: bool | None = None, load_on_pending: bool = False, query_class: Type[Query[Any]] | None = None, info: _InfoType | None = None, omit_join: Literal[None, False] = None, sync_backref: bool | None = None, dataclass_metadata: _NoArg | Mapping[Any, Any] | None = _NoArg.NO_ARG, \*kw: Any) → _RelationshipDeclared[Any]*

The library-situation is really not different from having types everywhere, and some people will do that too.

> catch bugs that you might otherwise miss.

People repeat this a lot. In about 22 years of writing ruby code, I have never ran into a situation once where I would have caught a bug through types. I don't understand why people keep on repeating this. Repetition does not make it anymore true.

Think in the opposite way: if types would have been necessary to begin with, why would ruby have been successful back in 2006? It was successful without types already. And types were never needed - they came because some people THINK they are needed. This is the biggest problem - the thinking part. They think they are right and all who do not use types, must be wrong and very foolish people.

It kind of is? All the partial-typing systems are too complex and usually broken in various ways. Compare to eg Elm or Gleam which are typed and super simple.

As an example, I may have a variable with types:

    const something = somelibrary.getSomething();

    const something = someWrapper(someLibrary.getSomething())

    function doSomethingWith(something) {
        ...
    }
    doSomethingWith(someLibrary.getSomething()

I would much rather have a language where the compiler complains if some variable doesn't have a static type, than a language where I can accidentally leave something untyped. I don't understand which case I would want a variable or function to not have associated static type information.

Except when their boss tell them to use Python, or they rely on one of Python libraries that their pet language couldn't provide via its powerful type system.

I guess my speculation is that not every language is good at everything. Sure you might want a better type system with Rust. But for data science?

All those bugs I constantly read about, they don't happen very often and are a good tradeoff. Maybe Rails and by Django are shielding me from some bug scenarios.

With Python I can’t see myself type-annotating everything (or bringing in pydantic anymore for that matter, it is indeed becoming a blight), but with TypeScript my process is turned on its head: I find it natural and easy to start writing with types and have everything fully typed, and I find the fact that it simply won’t compile if anything is off (compared to Python where it’s more like “one of my N type checkers/linters failed, oh well it still runs though) a useful constraint that gives peace of mind.

It is important to be able to understand the LLM generated code, often also to edit it by hand at times. Go lang has the middle ground whereby it's understandable with moderate effort while being statically typed with any necessary flexibility.

Cython is not in any real sense a replacement for a modern data/ml stack.

Python is mostly just glue

Virtualenv allows you to seamlessly run multiple Python ecosystems simultaneously, even within the same project directory. It's basically primitive containerisation mechanism that predates any actual containerisation systems on Linux.

You do not have to use it, but then you can easily slip into a sort of "DLL hell" (multiple incompatible library versions installed system-wide) with multiple projects — or need to bundle all dependencies within your project directly. None of this is specific to Python, really — any shared library system has the same challenge. How many other systems are there in active use making it as easy to use multiple incompatible versions of shared libraries per project or within the same project?

When in doubt, you can always retreat to the basics in Python world: put packages you need in a path of your choice, and point PYTHONPATH (sys.path) at it.

And yeah, I have written a lot of code to insulate Python in containers while allowing meaningful access to hardware and services. While at the same time not heaping more complexity and cognitive surface at the developer. Including writing my own container software to actually understand what's involved at a more detailed level so I know what I'm doing when trying to make this work with existing container software. (No, I don't run any of my container managers in production since I don't want to maintain it -- but this also means a bit more complexity in using existing ones)

It may be "easy" in trivial cases, but it is very far from easy if you want to make something that can cater to a wide range of scenarios.

Python typing is easy to dip in and out of. It handles None nicely; not as nicely as a true Optional, but enough for daily driving. The annotations are readable and simple. What more could I ask for, without asking for an entirely different language? Python typing catches a lot of bugs I'd otherwise have to tediously unit-test for.

The only thing I don't like about it is that it feels like it relies a lot on importing stuff from the swamp of the Python stdlib.

Could enable a different interface into approximate equality for floating point numbers: Equality.approximate(iota: float) -> bool

```python df.filter( pl.col("foo") == pl.col("bar"), ) ```

Sqlalchemy does something equivalent too, and I'm sure there are many others.

In any language, a function called `isEqual` could wipe your hard drive and replace your wallpaper with a photo of a penguin. Therefore, letting programmers pick the names of their functions is bad? No, obviously naming things for least surprise is the programmer's responsibility.

But when it's the symbols `==` instead of an ASCII name, it's a problem in language design?

(FWIW in Javascript, being unable to override == is actually a problem when you want to use objects as Map keys)

I understand why those exist, but they’re pure evil.

Consider using Shamir secret sharing to share a secret, D, among several people with two people required to recover the secret. D is a positive integer, such as a randomly generated 128 bit AES key you are using to encrypt your launch codes or credit card database.

For anyone not familiar with Shamir secret sharing what you do is pick a prime number, p, that is larger than D and another random positive integer A, that is less than p. Then give each person a pair of numbers, (i, (Ai + D) % p), where each person gets a different i (which should be a positive integer less than p...it is OK to simply use 1, 2, 3, ...). Let's let Di = (Ai + D) % p.

(This is for the case where you want any two people to be able to launch your missiles or decrypt your database. If you wanted 3 required instead of giving out (i, (Ai + D) % p) you would give out (i, (Bi^2 + Ai + D) % p) where B is a randomly chosen positive integer less than p. For 4 required add on a Ci^3 term, and so on).

Given (i, Di) and (j, Dj) and p it is possible to recover A and D.

Here's what that looks like in a language where the big int library uses an accumulator style, i.e., operations are of the form X = X op Y, where the ops are methods on the big int objects. Assume Bi and Bj are big int objects initialized from i and j, and Di and Dj are already big into objects, as is p. This particular example is using Perl. (This is very old code. Since 2002 you can add a "use bigint" pragma to Perl code and then it would look a lot more like the second Python example below).

  my $A = $Dj->copy()->bsub($Di);  # Dj-Di
  $Di->bmul($Bj);                  # j*Di
  $Dj->bmul($Bi);                  # i*Dj
  $Di->bsub($Dj);                  # j*Di-i*Dj
  $Bj->bsub($Bi);                  # j-i
  $Bj->bmodinv($p);                # (j-i)'
  $Di->bmul($Bj);                  # (j*Di-i*Dj)*(j-i)'
  $Di->bmod($p);                   # (j*Di-i*Dj)*(j-i)'  mod p
  $A->bmul($Bj);                   # (Dj-Di)*(j-i)'
  $A->bmod($P);                    # (Dj-Di)*(j-i)'  mod p

Here's what it looks like in a language with the ops as function calls taking the big int objects as arguments. This example is Python without using operator overloading.

  import operator as op
  def recover(i, j, Di, Dj, p):
    j_i_inv = pow(op.sub(j, i), -1, p)
    A = op.mod(op.mul(op.sub(Dj, Di), j_i_inv), p)
    D = op.mod(op.mul(op.sub(mul(j, Di), op.mul(i, Dj)), j_i_inv), p)
    return A, D

  def recover(i, j, Di, Dj, p):
    j_i_inv = pow(j-i, -1, p)
    A = ((Dj - Di) * j-i_inv ) % p
    D = ((j*Di - i*Dj) * j_i_inv) % p
    return A, D

OT: this reminds me of something I started to do once but never finished. I was going to write for each language we used at work that had a big int library but that did not support operator overloading a class that implemented a big int RPN calculator. Java, for example. Then recover would look something like this:

    calc = new BigRPNCalc();
    calc.do(j, i, "-", p, "modinv dup");
    calc.do(Dj, Di, "- *", p, "mod swap");
    calc.do(j, Di, "*", i, Dj. "* - *", p, "mod");
    D = calc.pop();
    A = calc.pop();

Expression `select(User).where(User.id == user_id)` does look simpler and cleaner than `select(User).where(eq(User.id, user_id)))`.

Maybe there is an actual eq function of sorts that allows that, and it's not a life-or-death difference here, but as far as convenience goes, it works well. And typecheckers are good enough to be able to let you know what's the return type.

Python is a lot more expressive than other languages and has a very terse syntax, and thus requires LLM to output much fewer tokens to achieve the same job compared to other languages.

Adding a few more tests to ensure data conformity on top of what you have to do anyway with a statically typed language still results in fewer tokens overall.

There is no way that Rust will be faster than simply specifying tests for an agent to run after it has generated code.