-
-
Notifications
You must be signed in to change notification settings - Fork 838
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
Pyproxy mixins #1264
Pyproxy mixins #1264
Conversation
e4b50a8
to
33a178a
Compare
33a178a
to
e899d1a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @hoodmane ,
thank for this pull request, it looks very impressive. From my first view I don't see any problems, the tests look nice on the mixins and the documentation is very well. The only "little" thing which bothers me are the comments about when you're not sure about something. I think these kind of thoughts must not be part of the source code, but that's only my opinion.
Separating the Javascript-parts from pyproxy.c into a new pyproxy.js could also be done within this pull request, but IMHO having all related C-JS-stuff in one file is okay.
@phorward Thanks for the review. I don't think this PR addresses the GC issues. I'll probably do that after this is merged. |
Yes, I found this already out, and I'm very excited about that change. |
Thank you @hoodmane that is ok for me. Let's wait for CI, and can you please merge the current master into your branch? |
So what's the status on this? Is this okay to merge @phorward? |
* Set up mixins in pyproxy.c * Add a bunch of documentation comments to pyproxy * PyProxy should only subclass Function when the Python object is Callable * Don't leak name, length, or prototype. Add tests * More tests, some final tuneups, more comments * Remove tests that show different behavior between Firefox and Chrome * Reduce repitition in getPyProxyClass * Update comment
This PR improves several things about
PyProxy
:Prior to this PR, fields called "name", "length", or "prototype" all showed weird behavior ("prototype" would be shadowed entirely, "name" and "length" show inconsistent results with the "in" keyword). Likewise "caller" and "arguments" were in all cases shadowed. Now the "name" and "length" inconsistencies are fixed, "prototype" is no longer shadowed (and setting and deleting the "prototype" field works as expected) but "prototype" shows some minor (and unremoveable) inconsistency with the "in" keyword. "caller" and "arguments" are now only shadowed if the
PyProxy
wraps a callable Python object, in other cases they behave normally.I also added a lot of comments and organized and simplified the logic for testing which abstract object protocols the Python object supports.
This is on top of #1175.