As somebody who's comfortable with Python and C++... ugh. Types are frankly kinda silly. They don't do anything, the language doesn't even ship a blessed typechecker, they don't speed up your code, they don't make it safe, they just add useless notation that some mutually-incompatible third-party tools grok. And the mutually-incompatible thing is what really rubs me wrong. They didn't sit down and define a bombproof type system; they just added an optional notation and let the community figure it out (like packaging). Years later, and the community has not figured it out (like packaging).

Compared to C++, where you can do incredible zero-overhead magic with the type system; for example duck-typing, once The Way, is now an absolute nightmare in Python's type system. Python typing is little but baggage and warts unless you've drunk the cool-aid and then you're horrified that people like me haven't.

(and, all that said, I'm quite excited about py3.11, it's great on performance and ergonomics)

I don't use typing with type checkers; I use it to remind readers of my code what types my functions take whenever that's not immediately obvious.

The history of Python means that coders make functions whose return is usually quite clear, but when it's not, I'm really glad I have typing.

Also, some libraries like Pydantic make use of types in a very clever and productive way.

They are not useless at all. Because they are introspectable new types of extremely ergonomic libraries have sprung up (FastAPI, Pydantic), as well as the developer experience improving.

Check Pydantic out.

Really cool for parts of your code in which runtime type enforcing is important (eg. external interfaces)

Three responses now, recommending the same third party stuff, which I already acknowledged the existence of. Kinda missing the point of what I had to say, isn't it?

> If you don't like the complexity of newer libraries and features, they're still optional aren't they?

Chances are you're not programming in a vacuum. These features will be used by third party libraries and you will have to read/understand this code.

Even in your in house codebase, there will always be co-workers that want to use these features.

The optionality of language features is not real. If they exist, they will be used, you will have to understand them, they will leak from other libraries, etc.

Ideally if it's a library you just need to know how to use it, not how it works internally right? Maybe that's too optimistic, but that's certainly how I use libraries in C++.

That's not even the case in C++ (I find myself having to step through Boost and even the standard library once in a while) but it's about 10x worse in a language that has so little static verification. If you use the library wrong then you find out via a runtime error you'll have to track down. Instead of, say, a type checker complaining about the type mismatch of your template parameter.

You can't always trust your libraries and you might have to fix bugs or dig in the source code to figure out how/why something works.

Trusting foundations is the only way anything in computing gets done.

If I’m at the point where I’m debugging 3rd party code, a little bit of unfamiliar Python syntax is the least of my problems.

> Trusting foundations is the only way anything in computing gets done.

Hu, says who? Says the junior developer so as not to get overwhelmed?

If you've done any kind of expertise work, digging under third party layers is a very regular exercise.

It’s not as much my code as reading my dependencies, troubleshooting others’ code, and the ecosystem sprawl. I keep up to date and pick and choose what I want.

A lot of these issues just aren’t there in C++, and you probably wouldn’t even try to share a codebase for something with someone who’s not another expert. …and you’re most likely working on something big.

The big thing that’s plagued Python since 3.x is the distribution problem. You can’t just hand someone a script and maybe another one to user-install some requirements. You need to BYO Python, dependencies, etc.

Things like types, library management, etc. are being handled by external tools. If I want to onboard someone to collaborate with me they really have to have my version of Python (so probably pyenv), Pipenv or Poetry, mypy or whatever, pytest or whatever, black, and have the same config for some of them.

The verbosity overhead of Go (or Nim, etc.) is worth the trade off to me for most of my uses of Python. I can just hand someone a binary and the dev just needs the language installed and maybe like goimports.

I’ve never been married to one language. I like to use them for their wheelhouse. I’ll still use Python for 1-offs or some things I can ship in a container, etc. that I’m only working by myself or with experienced Python people on.

A lot of this is that it’s really turning into more of an Analytics language. The output isn’t expected to be shared and everyone around you is a Python dev.

And I’m old. I started when Python was so pretty to my Pascal/C self compared to PERL (shudder). The documentation is still amazing for the language and standard library. (No Google, I want the actual docs.) And you could onboard almost anyone to work on it if they had any programming background because it was such a simple language.

The 2->3 shift was really only bad for complex legacy codebases and when you primarily deal with bytes vs Unicode. The latter is really painful anywhere. It didn’t bother me much. I usually just had to fix a few small things or it gave me a good excuse to kill something that should have been retired anyway.

Verbosity overhead? Nim is very close to Python.

> As someone who mainly sits in the C++ and not the Python space - why?

For the same reasons that you can't "just" use C++11 and ignore C++20.

The ecosystem moves forward, and you can't just sit behind no matter how much you would like to.