Seth Larson

I'm a bit surprised at the vitriol here for even just type hints, much less even static typing. I'll admit that static typing is probably more pain than most python devs are willing to pay, but I will die on the hill of type hints being an essential contribution to the language that vastly improves its capabilities.

But don't take it from me, take it from the people who wrote urllib3 [1], who insist that typing is even more powerful than unit tests--and they're the developers of a wildly popular library. "People are making it harder to develop without [type hints]" you say, completely ignoring the productivity boon that the type hints have provided to many other people. (I'm also not clear on how the existence of type hints makes it harder to develop without them.)

In my personal experience, adding type hints and enforcement to our code has eliminated entire classes of runtime errors, and I find that developing with them makes my life significantly easier. I'll admit some of that may be because dev tools are leaning on the hints, but I ask what's the alternative? You can't static-analysis your way to a definitive type in a dynamic language.

I'll try to respond point by point:

> I don't want ugly rust-like typing. [...] It looks horrible in Python.

You don't want a feature because... it looks bad? I could understand if it's "confusing" or "unclear syntax" or "makes it harder to read", but just "ugly" I have trouble both believing and understanding.

> 2. Requires…

> What if we intentionally made deprecated functions return the wrong result … sometimes? Every time it intentionally returns the wrong result, it logs the deprecation warning.1

What if we found that a highway overpass construction material was suboptimal, and we want people to use superior materials, so, every now and then, we send a chunk of concrete plummeting down to the ground, to kill a motorist?

Thanks to deprecating like we mean it, they're going to replace that overpass sooner than they would otherwise. You'll thank me later.

From the https://sethmlarson.dev/deprecations-via-warnings-dont-work-for-python-libraries that the post opens with:

> This API was emitting warnings for over 3 years in a top-3 Python package by downloads urging libraries and users to stop using the API and that was not enough. We still received feedback from users that this removal was unexpected and was breaking dependent libraries.

Entirely predictable.

Even many of those who saw the deprecation logging, and bothered to make a conscious decision, didn't think you'd actually break the API.

> We ended up adding the APIs back and creating a hurried release to fix the issue.

Entirely predictable.

Save yourself some anguish, and don't break API unnecessarily. Treat it like a guarantee, as much as possible.

If it's a real problem for ongoing development, consider using SemVer and multiple versions, like the linked article suggests. (With the deprecated branch getting minimal…

WebAuthN: https://en.wikipedia.org/wiki/WebAuthn

FIDO2: https://en.wikipedia.org/wiki/FIDO2_Project

Arch/WebAuthN:
https://wiki.archlinux.org/title/WebAuthn

U2F/FIDO2:
https://wiki.archlinux.org/title/Universal_2nd_Factor

TPM: https://wiki.archlinux.org/title/Trusted_Platform_Module#Other_good_examples_of_TPM_2.0_usage

Seahorse: https://en.wikipedia.org/wiki/Seahorse_(software)

GNOME Keyring: https://en.wikipedia.org/wiki/GNOME_Keyring

tpmfido: https://github.com/psanford/tpm-fido

"PEP 543 – A Unified TLS API for Python" (withdrawn*) https://peps.python.org/pep-0543/#interfaces

> Specifying which trust database should be used to validate certificates presented by a remote peer.

certifi-system-store https://github.com/tiran/certifi-system-store/blob/main/src/certifi/core.py

truststore/_openssl.py:
https://github.com/sethmlarson/truststore/blob/main/src/truststore/_openssl.py

"Help us test system trust stores in Python" (2022)
https://sethmlarson.dev/blog/help-test-system-trust-stores-in-python :

python -m pip install \
--use-feature=truststore Flask

This a a great example of good work getting 'upstreamed.' The go-to solution for using requests and urllib3 in the browser had been Koen Vossen's 'pyodide-http' package, which you'd install in PyScript/Pyodide and then call 'pyodide_http.patch_all()`. It monkey-patched requests and urllib3 to use the browser API's. [1]

Then 'pyodide-http' got adopted into the Pyodide-included packages[2], so you didn't have to specify it for install, just import it and run patch_all().

And now a similar technique has been incorporated directly into urllib3. (Not a direct port - as far as I know Joe Marshall and others did a full reimplementation so that urllib3's API's would be maintained as much as possible). [2]

Very cool.

Edit: Looks like there's a note to this same effect on Seth Larson's post about urllib3's future. [3]

[1] https://github.com/koenvo/pyodide-http

[2] https://pyodide.org/en/stable/usage/packages-in-pyodide.html

[3] https://sethmlarson.dev/urllib3-is-fundraising-for-http2-support#support-for-webassembly-and-emscripten

No, changing this breaks the world. A huge fraction of PyPI becomes completely invalid overnight, and the rest fails the expected version checks. Not to mention that the language is fundamentally designed around the expectation that modules are singleton. I've written about this at length before but I can't easily find it right now (I have way too many bookmarks and not nearly enough idea how to organize them).

Yes, you absolutely can create a language that has syntax otherwise identical to Python (or at least damn close) which implements a feature like this. No, you cannot just replace Python with it. If the Python ecosystem just accepted that clearly better things were clearly better, and started using them promptly, we wouldn't have https://pypi.org/project/six/ making it onto https://pypistats.org/top (see also https://sethmlarson.dev/winning-a-bet-about-six-the-python-2-compatibility-shim).