This should be called Python Type Server Protocol, no? Seems weird to mine the generic protocol namespace for a protocol that only supports Python. Especially coming from the company behind LSP, which actually is generic.
wolttam · 2026-10-26 18:52:51 UTC
It is namespaced under the pylance project. I also don't see any announcement here, just a markdown file.
100% - it would make more sense if they also supported elixir or other dynamic languages
pantsforbirds · 2026-10-26 18:59:54 UTC
I do wonder if it generalizes outside of python similar to how LSPs do.
rzzzt · 2026-10-26 19:23:16 UTC
Type Server Subsystem for Python
cobolexpert · 2026-10-26 20:20:05 UTC
Copilot+ Type Server Subsystem for Python Series S
Waterluvian · 2026-10-26 20:25:38 UTC
Copilot+ Type Server Subsystem for Python Series S .NET
kstrauser · 2026-10-26 20:52:44 UTC
…Server 2027.
nazgulsenpai · 2026-10-26 21:02:30 UTC
...Subscription Edition
keitmo · 2026-10-26 22:18:41 UTC
...365
wseqyrku · 2026-10-27 02:28:37 UTC
.PYTHON
MoltenMonster · 2026-10-27 05:07:59 UTC
For Teams
duckqlz · 2026-10-27 07:22:18 UTC
… Home Edition
vrighter · 2026-10-27 09:13:07 UTC
SP3
dacsson · 2026-10-27 13:43:27 UTC
MAX PRO
zemo · 2026-10-26 20:52:34 UTC
Language Server Protocol Server Subsystem for Type Server Protocol Servers for Python
warkdarrior · 2026-10-27 00:04:55 UTC
... for Workgroups
awesome_dude · 2026-10-27 01:17:06 UTC
Python Server Subsytem Typing - PSST
roarcher · 2026-10-26 20:47:54 UTC
This is the company that named its web framework "MVC". At least this time they're not eternally polluting search results for an industry standard term.
ameliaquining · 2026-10-26 21:59:07 UTC
I've usually heard it called "ASP.NET MVC" except when the former part was clear from context.
ta2345fa59be · 2026-10-27 12:42:03 UTC
MVC is still a general way of structuring code. Would it be the only way a MVC framework could or should be implemented for ASP.NET?
fnord123 · 2026-10-26 22:30:10 UTC
So now I need a TSP AND an LSP eating loads of memory?
ahgrta · 2026-10-26 18:53:47 UTC
Type-shed, type-server. When can this Python madness stop? How about using CORBA to make it even more enterprisey?
Why don't you spend your resources on F# instead of this nonsense?
SwamyM · 2026-10-26 20:02:45 UTC
> Why don't you spend your resources on F# instead of this nonsense?
Absolutely!
F# is criminally under-invested in.
rednb · 2026-10-26 20:12:15 UTC
Exactly what i came to write as well. I'd expect Microsoft to invest in F# so that python can slowly fade away the way php did.
paaloeye · 2026-10-26 18:55:59 UTC
Interesting, LSP, DAP, MCP, and TSP now...
intrasight · 2026-10-26 19:13:41 UTC
TSP : TriSodium Phosphate. Very good for cleaning up a mess.
paaloeye · 2026-10-26 21:28:30 UTC
From Wiki:
Trisodium phosphate was at one time extensively used in formulations for a variety of consumer-grade soaps and detergents, and the most common use for trisodium phosphate has been in cleaning agents.
So basically adding machine readable type-at-point queries as an lsp extension so Pylance and Pywright can be separated?
The 'result types'format is super python specific, like not having a for all binder. I don't think this specific schema will be used for any non-python languages.
0cf8612b2e1e · 2026-10-26 19:07:16 UTC
It kept with UTF-16. New protocol is a chance to correct that poor decision.
marshray · 2026-10-26 22:20:35 UTC
It's just an .md file and a few hundred lines of json schema defining some extension messages, not a bottom-up protocol revision.
ivanjermakov · 2026-10-26 23:53:00 UTC
What's wrong with UTF-16 for transport?
hmry · 2026-10-27 07:43:03 UTC
In LSP, UTF-16 is not just for transport. Source locations are also referred to by their UTF-16 offset. That means applications are required to store a persistent mapping from UTF-16 offsets to whatever they use internally, keep that mapping updated as the document is edited, and map back and forth constantly.
Oh well. It was primarily designed to be a good protocol for VSCode, not for any other users. That's just the price you pay when using a corporate standard.
Oh you're right, except since LSP 3.17 position encoding can be negotiated with clients/servers that support it. I initially got confused because my work with LSP started with 3.17 and I always used UTF-8 encoding.
Right now it's specific to Python but I think there are other languages w/o an official type checker that might benefit.
PHP, Erlang, Ruby, etc.
rjbwork · 2026-10-26 19:25:15 UTC
It's such a shame python got such mindshare. It's a disaster of a language and ecosystem that people keep bolting and hacking things that much better thought out languages have had for decades.
esafak · 2026-10-26 19:31:32 UTC
Worse is better. Avoid using it yourself and tell others; that's the best you can do.
mi_lk · 2026-10-26 19:32:33 UTC
OTOH I don't want to live in a universe where Haskell wins
lijok · 2026-10-26 19:33:20 UTC
Fascinating take.
What do you attribute Python's success to, in spite of being a disaster of a language and ecosystem?
johnfn · 2026-10-26 19:37:18 UTC
It's incredibly easy for new engineers to pick up. On the spectrum between "features easy for beginners but nightmarish for experienced engineers" and "features complex for beginners but great for experienced engineers" it always makes the tradeoff for the former.
dude250711 · 2026-10-26 19:40:04 UTC
Yes, just like Go, it's a junior developer onboarding language, that somehow managed to overstay its welcome.
theplumber · 2026-10-26 19:43:04 UTC
Go is awesome and has great ecosystem. I think if you want to just deliver Go is one of the best language out there. Of course as long as the project makes sense(I.e no client side/GUI stuff, there it gets messy)
konart · 2026-10-26 19:59:50 UTC
Some people live to shit on Go since you can't really do "crazy cool shit" as someone I knew put it.
Apparently you can't be a senior dev unless you "just here to deliver"
dijit · 2026-10-26 20:14:37 UTC
C++ is the "just here to deliver" language.
It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.
Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).
No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.
"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.
Go is a lot more elegant and well designed, but it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..
EDIT: if we consider speed a function of development time rather than runtime, of course at runtime C++ can be as fast as it gets.
stackghost · 2026-10-26 20:21:27 UTC
The dump truck that is C++ definitely goes just as fast if not faster than that Hellcat, though.
To me it seems more like C++ is the metal shop's old school 3-axis mill: effective and dangerous. Can do almost anything, including easily maim you unless you're continually vigilant.
Go seems like a CNC machine: just as effective, much less dangerous because it relies on digital safeguards and embedded controllers. You need to go to extreme lengths to make it do something it wasn't designed to do.
Python seems like lego. Shit simple to build things with, lets you start building immediately, fantastic for prototypes, but finished product is still just press-fit plastic bricks
dijit · 2026-10-26 20:24:04 UTC
Well, if we consider speed of development rather than speed of the runtime, the analogy holds better.
bheadmaster · 2026-10-26 19:45:55 UTC
If Go is a junior developer onboarding language, then I proclaim myself a perpetual onboarding junior.
dijit · 2026-10-26 20:06:53 UTC
And that's ok.
dizhn · 2026-10-27 10:06:39 UTC
It's no wonder then that Google used to be all in on Python in the 2000s as a language for juniors and then invented another language with similar users in mind. With AI becoming what it is they probably did not need to do the latter.
Python owes a lot to that initialish Google push where for a few years you couldn't get a job at google without knowing python or you could easily get a job if you knew python. Maybe both.
avaer · 2026-10-26 19:38:53 UTC
- Math + visualization libraries (which ironically have to break out of Python to do their job)
- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician
- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS
aaabbbbb · 2026-10-26 19:42:31 UTC
Marketing in academia, decent C-API that led to use in scientific Python.
The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.
kingstnap · 2026-10-26 19:48:26 UTC
Probably the batteries included Standard Library.
Cross platform interpreter.
NumPy and SciPy really set the stage.
chuckadams · 2026-10-26 19:57:11 UTC
It's definitely a better language than Matlab, and Numpy made it actually fast for that purpose. AI research really took advantage of that even before LLMs hit the scene.
rsalus · 2026-10-26 19:48:30 UTC
Definitely ease of use...
stronglikedan · 2026-10-26 19:50:57 UTC
well, for one, my boss can use it and kinda understand it, so it must be dead simple
Pxtl · 2026-10-26 20:01:26 UTC
It was the first language that actually felt ready-to-use, available for free-as-in-speech. Batteries included, robust online development community, sensible featureset, main libs that were designed bottom-up instead of top-down. I remember learning Java 1.2 or 1.4 after learning Python and it felt like a huge regression. Swing was a joke compared to TkInter (which was weak compared to proper GUI editors like VB but at least made nice scalable native-feeling GUIs and had a sensible API) and the standard collections were miserable without generics.
But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.
jacquesm · 2026-10-26 20:03:29 UTC
BASIC rebooted. Right at the right time too, BASIC was never going to thrive in the days of the internet.
I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.
thinkyfish · 2026-10-26 21:24:50 UTC
They provide binaries for almost every open source library for every popular platform. If you need something, whatever it is, python was and is probably the easiest way to install and use it.
TomBombadildoze · 2026-10-26 21:56:24 UTC
20 years working on Python. Two things have driven its success.
First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.
Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.
[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.
It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.
timschmidt · 2026-10-26 22:04:03 UTC
I'm not the OP, but it seemed to me that major teaching institutions settled on Python as a pedagogic language after previously having rallied around Java for same, and various other languages before that.
We've known for a very long time that shitty things can become very successful in this field and why.
LaGrange · 2026-10-27 11:28:03 UTC
It smells like an easy to learn language, it’s interpreted and other competitors in that category were highly specialized or got stuck with DHH.
In other words it’s easy to sell. Combined with the widespread anti-intellectual attitude in the software industry that’s enough.
Edit: it does help it’s genuinely a good scripting language.
brcmthrowaway · 2026-10-26 19:39:55 UTC
The packaging is a nightmare thats for sure.
Venvs, activate, deactivate, shitty scripts hacking on $PATH. How did this ever ship? Then there was poetry, `uv`, and maybe something in else in $CURRENT_YEAR.
Try to set it up on a new macOS, go on. Install a package from pip, and there's a bunch of garbage that won't let you do it.
It's horrible. Python packaging engineer is now an FTE, maybe that's what they wanted.
Pxtl · 2026-10-26 20:02:46 UTC
The fact that they didn't solve Venv when they did the breaking change in Python 3 is absolutely bonkers.
quotemstr · 2026-10-26 19:41:02 UTC
Python is pretty decent. What are you talking about?
okanat · 2026-10-26 20:04:58 UTC
The syntax and meaningful spaces are annoying. The dynamic typing is abused to hell in everything including the standard library. It has wacky paradigms like "exceptions instead of conditionals" or having "else" clause for loops.
It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.
It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.
theplumber · 2026-10-26 19:41:40 UTC
it could be worse like …PHP
benrutter · 2026-10-26 19:43:17 UTC
I work in python daily, it's not necessarily my favourite language, but I'd say it's mostly fine.
What languages are you thinking of specifically when you mention better thought out ones?
pphysch · 2026-10-26 20:01:48 UTC
They are a heavy C# user. Coke/Pepsi situation.
stackghost · 2026-10-26 20:14:34 UTC
I don't agree at all that it's a coke/pepsi situation. That analogy is for when two mostly-interchangeable choices develop tribal followings based largely on personal preference. Coke and Pepsi are both caramel carbonated soft drinks that are terrible for your health differing only slightly in flavour. Otherwise they're materially identical.
C# is strongly/statically typed, compiled, and quite fast (after the vm has started), whereas python is weakly/dynamically typed, interpreted, and generally slow as fuck. Those are two fundamentally different languages, how could it possibly be a coke/pepsi situation?
I think python is fantastic for certain use cases: gluing other tools together (like LAPACK or other ancient libraries), system automation, prototyping, exploitation (I think pretty much all of us were working on stealmybitcoin in python), and exploratory data analysis.
The problems arise when people try to write, say, gigantic GUI applications in python, or really anything with CPU-bound workloads. Part of being an engineer is using the right tool for the right job. Python is the wrong tool for lots of jobs. That shouldn't be a controversial statement.
pphysch · 2026-10-26 20:28:43 UTC
Numpy is over 2 decades old. Pytorch is a decade old. Python devs know what "right tool for the job" means and focus on solving problems instead of being language purists.
stackghost · 2026-10-26 21:15:24 UTC
This has nothing to do with purism. I use python all the time, where it makes sense.
What I don't do is cultivate a "favorite language" and make it my whole identity, and then take criticism of that language as some sort of personal affront. Python objectively has some serious flaws. That shouldn't make anyone emotional, and I don't know why people get their backs up like this.
pphysch · 2026-10-26 21:33:28 UTC
Who is cultivating a "favorite language"? I missed that part. Agreed that this should not be an emotional issue, that is unprofessional.
Problem with any popular language is an outsider sees one or two statistically-likely codebases that are total turds, and then gets one-shot by the Goomba fallacy.
stackghost · 2026-10-27 01:07:07 UTC
> Who is cultivating a "favorite language"?
I don’t know, but deflecting legitimate criticism of a language by calling it “language purism” seems pretty emotional to me.
Jtsummers · 2026-10-26 21:39:56 UTC
> whereas python is weakly/dynamically typed
It's strongly/dynamically typed, not weakly typed. Why do people keep getting this wrong? Has any version of Python been weakly typed? I know Python 2 and 3 aren't, perhaps the first version or ABC, its predecessor language.
wtetzner · 2026-10-26 22:34:58 UTC
> Why do people keep getting this wrong?
It's kinda funny to say people are getting it "wrong" when strong/weak typing isn't really defined anywhere or universally agreed upon.
In fact, even "dynamic typing" can be considered to be an oxymoron, since types are formally defined to be a static property of a language. A more correct term would be "uni-typed".
I'm not saying that the meanings you're using for static/dynamic and weak/strong are bad, just that chastising someone for getting them "wrong l" doesn't make sense for terms that are not widely agreed upon.
locknitpicker · 2026-10-27 16:42:29 UTC
You're trying too hard to play the role of the "aktually" guy. Assuming good intentions and taking a pass at replying would have been a better contribution to the discussion.
jelloroll42 · 2026-10-26 23:05:30 UTC
Java would be Coke to C#'s Pepsi
pphysch · 2026-10-26 23:46:41 UTC
Those are closer languages but my broader point is that these application-level languages are more or less interchangeable from a professional standpoint. A Java or C# pro should probably not spend time becoming a Python pro because they could have spent that time producing equivalent value in the languages they are already experts in.
rjbwork · 2026-10-26 20:30:55 UTC
Pretty much every other mainstream language bar JS. I'd say also Ruby because I also do not like a lot of its choices, but there's at least a kind of heady elegance to it in a REPL, though I would never want to work on a production system written in Ruby.
Frankly, I just really prefer statically and strongly typed compiled languages.
I did my last company's first Demo and MVP in Python after running through the Koans at my co-founder's behest and ultimately we decided that the production system would not be done in Python. There are some cool things about it - specifically I do like that annotations are real AOP seams, but the numerous footguns and lack of types and a compiler just make it a very annoying ecosystem to work in for me.
Quitschquat · 2026-10-26 19:44:19 UTC
I blame Perl 6
loeg · 2026-10-26 19:44:23 UTC
I’m not a fan either, but it doesn’t bother me at all. Who cares? Let the python people do their thing.
Toutouxc · 2026-10-26 19:44:45 UTC
As a Ruby dev I'm kind of primed to hate on Python a little bit, but I have to agree. I've written some Python over the years, I've tried to like it, but it just doesn't feel good to me. There are things that are really great about Rust, Elixir, C#, Swift, Java, Common Lisp... Sometimes it's the standard library, sometimes the package manager, sometimes a feature (borrow checker, pattern matching), sometimes a principle (everything is an object, the code is just data). In Python, everything is kind of meh. Like they came up with the list comprehension syntax and that was it for cool things.
Pxtl · 2026-10-26 20:05:31 UTC
List comprehensions? Really? I remember when they were pretty and I was learning them alongside other languages with higher order functions and Python's approach seemed to be the ugliest of its cohort. They were neither as logical as simple Lispy "take a function as a parameter" things like Ruby, nor were they the kind of clean and legible stuff we expect from Python.
Toutouxc · 2026-10-26 20:29:31 UTC
I'm not saying I personally like them, but they're not as bland as the rest of the language. FWIW, I watched 3 non-dev people around me learn Python in uni (biologist, lawyer, graphics designer) and they all liked the list comprehension syntax.
Comments
Perhaps the post title could use a tweak
Why don't you spend your resources on F# instead of this nonsense?
Absolutely!
F# is criminally under-invested in.
Trisodium phosphate was at one time extensively used in formulations for a variety of consumer-grade soaps and detergents, and the most common use for trisodium phosphate has been in cleaning agents.
Ref: https://en.wikipedia.org/wiki/Trisodium_phosphate
The 'result types'format is super python specific, like not having a for all binder. I don't think this specific schema will be used for any non-python languages.
Oh well. It was primarily designed to be a good protocol for VSCode, not for any other users. That's just the price you pay when using a corporate standard.
https://microsoft.github.io/language-server-protocol/specifi...
https://microsoft.github.io/language-server-protocol/specifi...
PHP, Erlang, Ruby, etc.
What do you attribute Python's success to, in spite of being a disaster of a language and ecosystem?
Apparently you can't be a senior dev unless you "just here to deliver"
It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.
Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).
No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.
"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.
Go is a lot more elegant and well designed, but it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..
EDIT: if we consider speed a function of development time rather than runtime, of course at runtime C++ can be as fast as it gets.
To me it seems more like C++ is the metal shop's old school 3-axis mill: effective and dangerous. Can do almost anything, including easily maim you unless you're continually vigilant.
Go seems like a CNC machine: just as effective, much less dangerous because it relies on digital safeguards and embedded controllers. You need to go to extreme lengths to make it do something it wasn't designed to do.
Python seems like lego. Shit simple to build things with, lets you start building immediately, fantastic for prototypes, but finished product is still just press-fit plastic bricks
Python owes a lot to that initialish Google push where for a few years you couldn't get a job at google without knowing python or you could easily get a job if you knew python. Maybe both.
- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician
- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS
The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.
Cross platform interpreter.
NumPy and SciPy really set the stage.
But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.
I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.
First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.
Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.
[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.
It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.
We've known for a very long time that shitty things can become very successful in this field and why.
In other words it’s easy to sell. Combined with the widespread anti-intellectual attitude in the software industry that’s enough.
Edit: it does help it’s genuinely a good scripting language.
Venvs, activate, deactivate, shitty scripts hacking on $PATH. How did this ever ship? Then there was poetry, `uv`, and maybe something in else in $CURRENT_YEAR.
Try to set it up on a new macOS, go on. Install a package from pip, and there's a bunch of garbage that won't let you do it.
It's horrible. Python packaging engineer is now an FTE, maybe that's what they wanted.
It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.
It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.
What languages are you thinking of specifically when you mention better thought out ones?
C# is strongly/statically typed, compiled, and quite fast (after the vm has started), whereas python is weakly/dynamically typed, interpreted, and generally slow as fuck. Those are two fundamentally different languages, how could it possibly be a coke/pepsi situation?
I think python is fantastic for certain use cases: gluing other tools together (like LAPACK or other ancient libraries), system automation, prototyping, exploitation (I think pretty much all of us were working on stealmybitcoin in python), and exploratory data analysis.
The problems arise when people try to write, say, gigantic GUI applications in python, or really anything with CPU-bound workloads. Part of being an engineer is using the right tool for the right job. Python is the wrong tool for lots of jobs. That shouldn't be a controversial statement.
What I don't do is cultivate a "favorite language" and make it my whole identity, and then take criticism of that language as some sort of personal affront. Python objectively has some serious flaws. That shouldn't make anyone emotional, and I don't know why people get their backs up like this.
Problem with any popular language is an outsider sees one or two statistically-likely codebases that are total turds, and then gets one-shot by the Goomba fallacy.
I don’t know, but deflecting legitimate criticism of a language by calling it “language purism” seems pretty emotional to me.
It's strongly/dynamically typed, not weakly typed. Why do people keep getting this wrong? Has any version of Python been weakly typed? I know Python 2 and 3 aren't, perhaps the first version or ABC, its predecessor language.
It's kinda funny to say people are getting it "wrong" when strong/weak typing isn't really defined anywhere or universally agreed upon.
In fact, even "dynamic typing" can be considered to be an oxymoron, since types are formally defined to be a static property of a language. A more correct term would be "uni-typed".
I'm not saying that the meanings you're using for static/dynamic and weak/strong are bad, just that chastising someone for getting them "wrong l" doesn't make sense for terms that are not widely agreed upon.
Frankly, I just really prefer statically and strongly typed compiled languages.
I did my last company's first Demo and MVP in Python after running through the Koans at my co-founder's behest and ultimately we decided that the production system would not be done in Python. There are some cool things about it - specifically I do like that annotations are real AOP seams, but the numerous footguns and lack of types and a compiler just make it a very annoying ecosystem to work in for me.
"unhinged" take