-
Notifications
You must be signed in to change notification settings - Fork 246
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
Lookup classes in normalized builtins before trying sys.modules #427
Lookup classes in normalized builtins before trying sys.modules #427
Conversation
This logic was removed in b683c25, possibly under the assumption that all builtins exist under the "builtins" module - but this assumption is not correct, since some builtins like "method" are not available as "builtins.method". That's what "_normalized_builtin_types" is for (which was unused until this fix).
4bb988c
to
108ff8e
Compare
Okay, had some time to look at it again.
I added a test for this regression - ensures that builtin types that won't be found in |
P.S, I added a debug print in Here are the results before:
(notice all those that were mapped to non- After the fix:
|
Sorry for the slow response. I read over the code and the changes seem reasonable. I'll merge this and let the CI do the test work. If the CI starts failing we can go from there. |
The changes seem okay in https://travis-ci.org/github/tomerfiliba-org/rpyc The only thing of note would be to add a unit test to prove #426 is fixed. If you want the credit, I'd be glad to accept a PR for it. Otherwise, I'll get to adding a unit test when I get to it. Again, thank you for the contribution! |
Thanks for merging. About the unit test - what's common to If you deem a specific test for the case of #426 is relevant here, I can post a PR adding one, sure. |
Clearly, you have put more thought into that unit test then me. I've added a comment in |
thank you! |
This logic was removed in b683c25, possibly under the assumption that all builtins exist under the
builtins
module - but this assumption is not correct, since some builtins like "method" are not available asbuiltins.method
.That's what "_normalized_builtin_types" is for (which was unused until this fix).
Resolves the immediate issue in #426, but IDK if it breaks anything else along the way 😅
Few notes:
builtins
)ns["__class__"] = _builtin_class
is done, but it's later assigned again:ns['__class__'] = class_descriptor
, whereclass_descriptor
is aNetrefClass
. I tested both cases (with the override, and without) and I couldn't tell the difference. Perhaps the flow taken inNetrefClass.__get__
is always to get the object and not its type? Need to see further. Either way, we should either skip the override, or remove the (unnecessary & misleading) first assignment. Wdyt?builtins
were still using their matching local builtin. In that case, we can probably narrow down_normalized_builtin_types
to contain only the builtins not accessible viabuiltins
, liketypes.BuiltinFunctionType
andtype(None)
, ... and possibly we should do another "sweep" on builtins to ensure that none were forgotten?Marking as draft, until we decide on those discussions.