Skip to content
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

Add missing nullptr checks in atomlist #220

Merged
merged 1 commit into from
Jan 20, 2025

Conversation

frmdstryr
Copy link
Contributor

No description provided.

@MatthieuDartiailh
Copy link
Member

Thanks can you rebase to get the formatter happy.

@@ -785,16 +785,26 @@ class AtomCListHandler : public AtomListHandler
{
static char *kwlist[] = { "key", "reverse", 0 };
// Get a reference to builtins (borrowed ref hence the incref)
cppy::ptr builtins( cppy::incref( PyImport_AddModule("builtins") ) );
cppy::ptr builtins( cppy::xincref( PyImport_AddModule("builtins") ) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we doingAddModule here instead of Import? If we need a builtin function from globals, that should be pre-fetched on module initialization.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not remember the details but I likely followed an example. I would like to fully move away from global static and properly use module state (and we could store super there) but I have no idea if I will find the time to do so.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But hold on here. We seem to have deviated quite a bit from the original code, by calling a builtin and returning before the observer code. What exactly is going on, and why have we deviated so much from the original code?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once again I do not have the whole history in mind but I think we were relying on a private function to sort the list that disappeared. However I do not remember why I went with super rather than looking up the method directly on list. It may have just been simpler.

@MatthieuDartiailh
Copy link
Member

I will be worth revisiting this in the future to see if we can improve but the changes here make the code more correct and there is no reason to delay them so I will merge once the CI is green.

Copy link

codecov bot commented Jan 20, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.67%. Comparing base (10447ae) to head (f006704).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #220   +/-   ##
=======================================
  Coverage   97.67%   97.67%           
=======================================
  Files          24       24           
  Lines        1074     1074           
  Branches      162      162           
=======================================
  Hits         1049     1049           
  Misses         12       12           
  Partials       13       13           

@MatthieuDartiailh MatthieuDartiailh merged commit 9b80362 into nucleic:main Jan 20, 2025
18 checks passed
@sccolbert
Copy link
Member

Now that this is merged, I think we need to avoid going thru super to call List.sort. We should be able to access that method directly via the C-api and short-circuit all of the super logic. atomlist is not designed for multiple-inheritance, so this should not be an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants