-
-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Deep collections.abc.Iterable
type-checking 😬
#344
Comments
It's not safe to inspect the contents of an iterable, because that might change the value - think of a file object, for example. |
...heh. @TeamSpen210 defends the indefensible. You're both right, of course. In the general case, deep type-checking of arbitrary iterables is dangerous. So-called "one-shot" iterables like generators are yet another example of iterables that cannot be safely iterated. To even look at them is to destroy them. They're like an inverse Medusa. 🐍 But @beartype was born for danger. This is why the next next release of @beartype ...so,
And... that's it. I think, anyway. Technically, this feature request is a duplicate of long-standing decades-old feature request #53. But let's leave this open as a gentle reminder to myself that I should actually do this before the Heat Death of the Universe. I promise nothing and deliver even less. |
collections.abc.Iterable
type-checking 😬
It may be worth considering While BIG DATA certainly isn't lying about this case, it is, in the finest BIG DATA tradition, opaque as to be nearly deceptive. That is to say... from the examples, one could blithely assume that bearcheck would (for example) say @leycec I think this issue could fork in two directions "doc bug" or "behavior bug"? If "doc bug", we should probably float a big-fat-warning in the demos describing the current partial support for collections deep checking. If "behavior bug", it might be good to work out the behavior for procedural checks using In the Do you think adding a non-random-sampling, single element check via Perhaps the following deep-checking heuristic for
And deep-check Collection with the same logic:
Happy to pitch in a bit on docs or code if you think it'd be useful. |
MASSIVE COMBO! But first, big apologies for the long delay in my reply. The @beartype 0.18.0 release was a shambolic zombie that lurched about and destroyed everything including the entire Python ecosystem. Repairing that took intestinal fortitude and a willingness to roll almost everything back. This is why I'm currently clutching a teddy bear. Back to your stunning thoughts...
🤣 😭 You're the Big Typing Boss, @asford. As always, I defer to your wisdom. You're right about everything, of course. Doco concerns are especially germane. Because I coded rather than did docos for a year, our docos are currently also a shambolic zombie that is rifling through your pockets while muttering, "Code... Code!" Our docos are in dire need of renovation is what I'm saying. It would be spectacular if somebody who is not me could eventually document exactly what @beartype does for each type hint factory. It's no longer obvious to anyone (including me) what @beartype is currently doing, exactly. For example, we should document:
The ideal home for this documentation might be a new
Seriously. The "why not both?" girl is correct, as she always is. The current behaviour is mostly undocumented, which is bad. But the current behaviour also fails to deeply type-check collections annotated by Documentation should probably take priority there – because documentation is the low-hanging fruit, right? In theory, somebody who is not me could even bang out documentation on our wiki without my permission or involvement. In practice, I would love that. I permit everything that I'm uninvolved with.
Totally! Yes! Absolutely! ...*for various definitions of "totally," "yes," and "absolutely." This is actually my next action item. I'm currently hip-deep in unnecessary micro-optimizations for the deep dictionary type-checking shipped with @beartype 0.18.0. I belatedly realized I could eliminate one excess statement for each such type-check in the code @beartype dynamically generates to type-check dictionary key-value pairs. Nobody cares. Yet, I care. Why? It's unclear. "Asperger's, mumble-mumble, something, profit" is probably the answer here. After that, deep type-checking for all remaining collections that are safely type-checkable by simply inspecting their first items via
...heh. You're really clever, huh? Yeah. You've already guessed exactly what @beartype 0.20.0 is probably going to do. Probably. How did you guess that? Are you in my brain? Are you in telepathic communication with a parasitic brain worm currently rifling through my memories? If so, please ask where I left the salt. It's a conundrum and my stomach is demanding salty stuff.
😮 😨 😱 Let's pretend you didn't just suggest a new |
Am i missing something or is this not implemented.
But it works with list:
The text was updated successfully, but these errors were encountered: