You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm experiencing an issue when using Nuitka to package a project that relies on MNE-Python. The problem appears to be related to the _get_argvalues function in MNE, which attempts to access frame information but fails due to Nuitka's handling of frame dictionaries.
The related issue on Nuitka's GitHub is documented here: Nuitka Issue #2995.
Describe your proposed implementation
As mentioned:
One possible solution would be to modify _get_argvalues to ensure that the frame dictionary is populated correctly. Currently, the function relies on frame inspection through inspect.currentframe() and stack traversal. However, Nuitka does not populate the frame dictionary until an exception occurs, which makes this approach unreliable.
Here are two alternative methods:
Annotate functions: Annotate specific functions so that their frame dictionaries are always populated, even if no exception occurs. This would require a custom decorator or configuration within MNE to forcefully populate the frame.
Use locals() directly: Modify _get_argvalues to use {locals()[var_name] for var_name in inspect.getargvalues(inspect.currentframe())[0]} to access argument values directly from locals() instead of relying on stack inspection. This approach avoids the need to traverse the frame hierarchy and should work more reliably with Nuitka.
Describe possible alternatives
Another possible alternative is to inject __import__("inspect").currentframe().f_locals.update(locals()) before calling the base class. This workaround could populate f_locals to ensure that derived classes have access to necessary parameters. However, this would require changes in all derived classes and may not be feasible in the long term due to maintenance concerns.
Among the approaches, using locals() directly appears to be the most efficient and portable solution.
Additional context
No response
The text was updated successfully, but these errors were encountered:
after reading the thread at Nuitka/Nuitka#2995 it sounds like the issue is actively being addressed within Nuitka, so, nothing urgent to do here? I'm open to a possible refactor of _get_argvalues to remove its reliance on what is a CPython implementation detail, if you're interested to try it @H0I00.
CrazySJX
pushed a commit
to CrazySJX/mne-python
that referenced
this issue
Oct 30, 2024
Describe the new feature or enhancement
I'm experiencing an issue when using Nuitka to package a project that relies on MNE-Python. The problem appears to be related to the
_get_argvalues
function in MNE, which attempts to access frame information but fails due to Nuitka's handling of frame dictionaries.The related issue on Nuitka's GitHub is documented here: Nuitka Issue #2995.
Describe your proposed implementation
As mentioned:
One possible solution would be to modify
_get_argvalues
to ensure that the frame dictionary is populated correctly. Currently, the function relies on frame inspection throughinspect.currentframe()
and stack traversal. However, Nuitka does not populate the frame dictionary until an exception occurs, which makes this approach unreliable.Here are two alternative methods:
locals()
directly: Modify_get_argvalues
to use{locals()[var_name] for var_name in inspect.getargvalues(inspect.currentframe())[0]}
to access argument values directly fromlocals()
instead of relying on stack inspection. This approach avoids the need to traverse the frame hierarchy and should work more reliably with Nuitka.Describe possible alternatives
Another possible alternative is to inject
__import__("inspect").currentframe().f_locals.update(locals())
before calling the base class. This workaround could populatef_locals
to ensure that derived classes have access to necessary parameters. However, this would require changes in all derived classes and may not be feasible in the long term due to maintenance concerns.Among the approaches, using
locals()
directly appears to be the most efficient and portable solution.Additional context
No response
The text was updated successfully, but these errors were encountered: