Skip to content

Fixed recursive dependency in clr module initialization #1602

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

Merged

Conversation

lostmsu
Copy link
Member

@lostmsu lostmsu commented Oct 16, 2021

What does this implement/fix? Explain your changes.

There was a recursive dependency in clr module initialization when a public class that implements IEnumerable exists in the global namespace.

The fix is to delay updating clr module dict with contents of .NET namespaces until after our internal modules are loaded because .NET classes might depend on our internal modules to be initialized. In particular, any class implementing IEnumerable needs IterableMixin from collections.py

Does this close any currently open issues?

#1601

Checklist

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change

…a public class that implements IEnumerable in global namespace

pythonnet#1601

the fix is to delay updating clr module dict with contents of .NET namespaces until after our internal modules are loaded
@lostmsu lostmsu merged commit 3f335db into pythonnet:master Oct 16, 2021
@lostmsu lostmsu deleted the bugs/GlobalClassDerivedFromEnumerable branch October 16, 2021 23:44
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.

2 participants