I've found it way more hit and miss in terms of quality. From some examples I gave:

- JSON: Yup, stdlib is good here

- HTTP client: There is urllib.request, although people maybe reach for requests more.

- HTTP server: No, it's just some super basic thing (it's not even 'nice' to write for local dev). Would never let anything here near production.

- Unit testing: Yes, I think unittest is pretty good (I actually like it a lot, and think pytest is overrated).

- Crypto functions: No, not equivalent. There is hashlib but basically anything else you're pointed at pycrypto or cryptography with all the associated ecosystem nonsense (oh I need a Rust compiler now? Great...).

The difference is Python _has_ all of these things in the standard library, but the quality is super mixed, and not all of them are suitable for real use.

I would not agree with that assertion. Just off the top of my head, being familiar with both:

- context

- net/http as a full server framework, not just a request library

- net/http/pprof

- runtime/pprof

- runtime/trace

- embed

- testing as the canonical, required test framework

- net/rpc

- net/http/cgi

- net/http/fcgi

- net/http/httptest

- os/signal with integrated channel-based delivery

- sync/atomic with language-aligned memory model semantics

- runtime as a documented and supported API surface

In my experience, people building APIs w/ python are almost always using frameworks, while people building APIs w/ golang are almost always using stdlib