> The red flags were there, it doesn't even have an official package manager.

I think you may have several other misconceptions about what Unix means.

I started learning Python when it was barely at version 1 precisely because there was no real static type checking. If I wanted that, I would just write the program in C or its variants. I wasn't excited about type hints because developers became super judgy if there weren't any. I just want to know why you're using Python if you want stronger typing and feel the need to change the entire language instead of using another one yourself.

Progressive typing gives you the option to type check when and if you want or need it. You don't _have_ to type. If things get really hairy but you know it's right, you can focus on the code instead of the typing and efficiently complete your task.

There's also something fundamental about taking a dynamic language like Python or JavaScript and adding typing versus taking a static language and adding dynamic typing (e.g.`auto` in C#). The dynamic language allows modifications that are _really_ convenient if not a little hacky that you just can't easily express without big refactors in static codebases. Things like tagging objects with properties, making quick anonymous structs (before that became a thing in modern languages) so you can return tuples of values, other constructs like dynamic functions or whatever. Progressive typing is just so much more expressive

> taking a static language and adding dynamic typing (e.g.`auto` in C#)

Assuming you meant C++ - no, auto is not a even a tiny bit dynamic. It's still fully static typing, but with type inference.

The compiler will still prevent you from calling a method which doesn't exist.

Ah yes, my mistake. `auto` is C++. I was thinking of `dynamic` and `var` in C#.

Unfortunately, while `dynamic` is used for dynamic typing in C#, `var` is just type inferenfe like `auto` in C++.

Even "dynamic" isn't a true dynamic in C#, it ends up invoking methods via reflection, and using it for anything other than foreign COM objects is a massive code smell.

Probably because a lot of programmers don't get to choose the language they are using. They have a job developing some existing app that is already written in Python, but they wish it wasn't Python. They don't have an option to rewrite the whole codebase in Rust or whatever, so the best they can do is advocate for Python to evolve to be more like languages they do like.

I think this is exactly it. My gut instinct is just "Why the obsession with adding static types to Python, just use a language that already has good static types".

As you say though, not everybody gets to choose their language, and I certainly wouldn't choose Python if I could possibly help it, so if we can add good static types to Python, it's still not a great language, but it's much improved by static types.

I’m a Pythonista of two decades who is working with typescript (on the backend) for the past two years and absolutely loving it. I don’t like the js part, but it doesn’t matter too much except when you’re working with numbers, which are a bit insane.

If anyone built a typescript layer on top of Python, I’d cheer that effort. If that new thing from the article will be that, I’m stoked.

Or a better python layer on python.

People asking why statically typed python: consider that it's the #1 language on GitHub (assume ts and js are different) and LLMs are really good at generating it.

But most people in our profession get to choose their job, don't they? Why would a Python project hire a rust programmer? Why would someone who hates Python work on a Python project? I feel the same way. Sporadic use of type hints is nice, and I use it sometimes for reference, like a very succinct comment. But if I want a typed language, Go, Dart, C or even Java are right there.

Because sometimes people choose their jobs prioritizing pay, location, title, company, project, role, coworkers, etc. and the language they will primarily use (or even use on a secondary basis) is a lower priority concern.

In my case, I have, in the pursuit of my engineering goals, had to dig into a Python component that I did not normally work on or intend to work on. I am thankful it had type hints.

But none of these reasons should trigger a "I'm going to change this fundamental thing about x because I don't like it".

I don't have anything against typing. I just get annoyed when it gets out of control in a language it wasn't part of to begin with. Just look at how complex typescript typing is to see where it can go.

Used pragmatically it's fine. When it's out of control we might as well switch to another language.

The entire ML ecosystem is in python these days. I had a project at work that was Python because of that. Type hints saved me a lot of work in easing other people’s code.

> Why would someone who hates Python work on a Python project?

I hate every language! For different reasons. But I still like programming.

Even if we have some choice of jobs, your model only works if programmers have language as their only or most important requirement when job searching. There are lots of factors that might make a job more or less desirable aside from programming language, like location, salary, team, business domain, and so on.

Seems pretty plausible that someone can dislike python and still like a job because it checks other boxes.

> Why would a Python project hire a rust programmer?

> But most people in our profession get to choose their job, don't they?

Let's say someone has only worked in Python professionally but dislikes it. They spent nights & weekends learning Rust. Now they want a Rust job. Because a Rust project would not hire a Python programmer, this person who hates Python is stuck working on Python projects.

It's attitudes exactly like "Why would a Python project hire a Rust programmer?" that keep people stuck in languages they don't hate. Those attitudes are the reason a senior software engineer with over a decade in the field can't switch tech stacks. Without that attitude, job postings would be written for programmers, not python programmers, and the job market would be better for it.

> most people in our profession get to choose their job

Choose, yes, but from a finite set.

> Men make their own history, but they do not make it as they please; they do not make it under self-selected circumstances, but under circumstances existing already, given and transmitted from the past. The tradition of all dead generations weighs like a nightmare on the brains of the living.

— Karl Marx, "The 18th Brumaire of Louis Bonaparte"

C is basically untyped but makes you type out the types. This is not what modern type checking is; it’s usually the other way around - you specify types where you want them checked because it gives you confidence that the program is correct.

> C is basically untyped but makes you type out the types. T

This is grossly incorrect.

I feel like if you think about it for 20 seconds you can come up with a lot of good reasons, so I question your motivation in posting this.

I personally just love Python type hinting for testing purposes. So I can avoid types while prototyping or playing with architecture, but once I have something I'm happy with, I find that adding types allows me to gain confidence in the program while having fewer tests, and generally making it easier to refactor further.

And full typing is also a great first step for rewriting in another language.

Python's got a pretty incredible library ecosystem, and it's easy to get a project up and running quickly. The big problems with it start to appear as you cross the 10k+ sloc / 3+ dev thresholds; if things are changing quickly, the iteration velocity the duck typing provides can quickly become a big problem.

Type hints fix this by allowing you to ensure your contracts are upheld while your team continues to move. If you don't find yourself needing them, you probably don't have a team that's trying to ship and iterate super quickly, or your project is still at the one-off script scale.

The entire ML/AI ecosystem is in Python for the most part these days, so if anyone wants to get involved it means needing to touch Python to some degree. So, many developers might get handed projects that require working in Python, but would really prefer not to give up all the nice things that come from a modern statically typed language.

Personally, I'm one of those people that got converted over to statically typed languages, as I spent a large part of my early career in startups using Ruby. I don't think I could ever go back after using Go, TypeScript, and Rust over the past decade or so.

typed python is amazing for building understandable applications. I will never go back.

you can obviously still use it untyped to hack together scripts, but I still find myself leaving annotations for clarity.

I've been using it since the mid 2.x days and find the style we were writing back then to be incredibly dated.

I guess there's something about Python that just makes it really easy to read and write for me. I haven't found another language that fits the vibe. From my experience, the resentment towards stronger typing comes from developers misusing it.

Sometimes you need to write a script that is too large for a reasonable bash script but too small to make a full program. In those instances, I tend to reach for Python because of its massive standard library. I often don't need any additional dependencies. But when I use python I absolutely want types. It makes IDE-features like auto-completion so significantly more effective when your editor actually knows what type every variable is. And of course adding types provides the obvious benefits to code clarity, and the additional error-checking that type checking is.

Also its super hard to find non-crypto-currency rust jobs, but python jobs are pretty common.

Python’s typing is so different from C’s that there should be a different word for it. Typing in C is about storage. Move the stack pointer 8 bytes to make room for my integer. Move it another 8 to make room for a pointer to a character. When I deference it, write just one byte.

Python typing is about machine checkable properties of your program. Consider a function foo that takes a dictionary keyed by uuids, reads from it, and returns some kind of information. We can check all sorts of properties without ever running the code. Accidentally construct a dictionary keyed by strings instead of uuids? Rejected, wrong argument type. Accidentally modify the dictionary in the body of foo()? Rejected, if you wrote Mapping[UUID, Any] for the argument type. Mapping alone does not allow you to assume mutability. So many of the errors I make in Python, I can declare my intention not to make, and then check to see if I’ve committed them.

C typing also provides machine checkable properties of your program in the same way, it's just very bad about it.

C types are almost entirely unlike modern type-checking

It's an old debate.

I used to prefer dynamically typed languages for most tasks, and saw attempts at statically typing everything as some kind of [compulsion][1].

At work, we were writing a bunch of tests and tooling in python, and the team lead at the time insisted that we type things and lint with mypy strict as if it were a compiler.

I said to my teammate "this is so stupid, if you want to know the types of the parameters, you read the documentation comment right there in the definition. If you want to know more, you read the test. If you want to know even more, you read the source."

My teammate replied, "YOU will write a function with good documentation, thorough tests, and a comprehensible definition, but as an organization grows, a shrinking percentage of code will be written that way. These automated checks prevent the worst from coders who care less than you do."

I had no retort, so there is that.

[1]: https://github.com/dgoffredo/stag?tab=readme-ov-file#why

i type hint for the poor bastards who have to use my code. it's a lot more pleasant to read and reason about.

Yeap, type provides a really good baseline for a documentation. A good documentation is really needed when debugging dynamically typed language python.

Man, I feel the exact opposite. Working without types, even if it's just type hints, feels like I'm stumbling around in the dark. I want to know what stuff is, not just YOLO my way through everything.

Looking at my Python before I began using type hints and data structures such as dataclasses, typevars, etc I was still type-checking a function's argument, but it was very manual and messy. Nowadays, my code is so much cleaner, concise, less error-prone, and much easier to revisit after a long period away. IMO there isn't a single downside to leaning heavily into types, even if they're sorta "fake" like they are in Python.

If I use python it's because I need numpy or pyplot lib. For anything else I'd use a sensible language

> because developers became super judgy if there weren't any

Who? People on your team or randoms complaining about your open source project? If it's the latter, you can tell them to get bent or write their own type stubs if it bothers them. Type hints are fully optional in Python.

Adding types to Python always feels like pissing in the wind when you're passing around huge and ugly dataframes.

Sounds like Microsoft out litigates instead of out competes.

This is from Reddit, what were you expecting?

Thank you so much for posting this. The original logic was clear and it had me excited! I believe this is useful because compression is very common and although it might not fit perfectly in this scenario, it could very well be a breakthrough in another. If I come across a framework that could also benefit from this compression algorithm, I'll be sure to give you credit.

In a world where people are eviserated for being too woke, I have no empathy for this former tech CEO who was arrested for domestic violence. You can't have your cake and eat it too. If you fire and layoff DEI departments and the lowest performers, why are you crying victim when you get arrested for violent assault?

I think this case is orthogonal to woke and DEI. Would you knowingly hire anyone who's physically assaulted anyone for any position, let alone for that of a CEO?

I certainly wouldn't.

"woke"

I'd like to see more people spell out what they mean by that overused term.

I think the article made it very clear that there is a distinction between an arrest and a conviction.

But I guess it's very easy for you to write such a comment without ever establishing that the person is actually guilty, as if, in domestic violence, people should be considered guilty unless proven innocent? Thankfully you are not a prosecutor.

I don’t think the arrest is really the important part. It’s the account by the officer of what they saw.

If there had just been a report with that info, and no arrest the damage to him would have been about the same.

The VCR era was peak physical media.

Nah, the peak was in the 2000s with DVDs. Then streaming services started, and the HD disc format war and price hikes for HD discs didn’t help.

VCR let you record anything. Something on TV you wanted to watch later? Set the timer, it recorded on that channel at that time.

A DVD might have been peak consumer, but it didn't have nearly the versatility of VCR. Hell, I could record 6 hours of content on 1 tape!

I guess it depends on how you define peak. With regard to sales of prerecorded media, DVDs were the peak. For TV recording, DVRs were so much better quality-wise and more convenient than VCRs.

Enshittification already started with DVDs with all the "you can't do that" stuff blocking fast forward etc for parts of the video.

Yeah, I was lucky to have DVD players with a mod chip that defeated those restrictions.

100%. Nothing else like it. Your own controllable media and DVR with full control.

Thank you so much for this, I have trouble communicating time from maps even though its often so interconnected and this concept opens it up.

Security usually allows simple HTTP requests and REST is the quickest way to get started.