Is `beartype.door` still O(1)?

This commit is extremely exciting. I really like the typechecking ideas in awfutils, and this is something I’ve been hoping to see in @beartype for a long time. However, I worry about the overhead involved in inserting tons of assert() calls within the bodies of potentially every function in a codebase. I sometimes write code where almost half the statements in a function are annotated with an inline hint. In a 7-figure line count codebase, won’t we run into significant performance overhead, even if the typechecking itself is O(1) in the data?

Can anyone think of any easy way to benchmark this?

[langfield]

Right. The time complexity of PEP 526 compliance over the lifetime of a Python process could be considered O(k) time for k the total number of annotated assignments repeatedly type-checked by @beartype. Each k incurs a real-world wall-clock cost of at most 1μs, assuming no crimes against humanity like __isinstancecheck__() . For all k < 1,000,000, the total real-world wall-clock costs should still be less than a second over the entire lifetime of the current process and thus imperceptible to glorious fleshy meat suits such as ourselves.

Well, you’ve got me there! Sounds like it’s a non-issue, despite being O(k) in the number of annotations. As for the import hooks. Well, all I have to say is that when you’re taking an extreme measure (and I think doing all of this is an extreme measure), it seems polite to make the toggles opt-in instead of opt-out. I suppose the whole thing is of course opt-in. One of the things I like about the existing decorator is that it is very explicit. Import hooks scare me because I think I might forget that I’m using them, and leave them on when for some reason or another they shouldn’t be.

Anyhow, I think the concern has been addressed. Feel free to close!

[leycec]

Import hooks scare me because I think I might forget that I’m using them, and leave them on when for some reason or another they shouldn’t be.

Right? Import hooks fundamentally violate Python’s “Explicit is better than implicit!” maxim, which is perhaps not so good. My cynical suspicion, however, is that most users simply don’t care about purist ideology the way we do. As typing zealots, we’re mostly fine with all of the manual legwork that @beartype currently mandates. This is a useful tradeoff for people like us, because we retain full and total control over runtime type-checking over all time and space. In return, all @beartype demands is our scarce minutes, precious lifeblood, and eternal souls.

But most users aren’t like us. Most users don’t have the resources or inclination to manually manage boilerplate churn like that. Decorating every class and callable across a million-line codebase with @beartype.beartype is a hard blocker – and I feel that real-world pain. It’s understandable.

Import hooks fill that adoption gap by eliminating the current prohibitive cost of @beartype’s buy-in. Gah! Tech jargon, thy name is this thread.

Thanks so much for all the ongoing excitement, @langfield. If you’d like to see whitelisting or blacklisting features like the above @beartype_no_pep526, it’d be great if you could open up a new issue. Remind us all of my hollow promises to do something. 😄