Description

SolarLune

opened on Oct 23, 2025

Issue body actions

Hey, there. It's really cool to be able to run Python in Go! I'd like to congratulate you on this project, it might be exactly what I've been looking for when it comes to an easily embeddable scripting language.

I just noticed that py.RunFile() and py.RunCode() don't handle a nil py.Module pointer when deciding to create a new module. I feel like that would lessen the friction on using it, since if you run multiple files and want them to be in a single module you currently have to call two different RunFile() / RunCode() calls that are essentially the same (just with nil as the inModule argument the first time).

Basically, currently I'm doing this:

var mod *py.Module

...

// In a for loop for mutliple .py files

if mod == nil {
	mod, err = py.RunFile(context, fpath, py.CompileOpts{UseSysPaths: true}, nil) // Returns a new module
} else {
	mod, err = py.RunFile(context, fpath, py.CompileOpts{UseSysPaths: true}, mod) // Adds onto the existing one
}

and it would be easier to just do this:

var mod *py.Module

...

mod, err = py.RunFile(context, fpath, py.CompileOpts{UseSysPaths: true}, mod) // Returns a new module on first run because 'mod' is nil, adds onto the existing module afterwards

I believe to implement this I would just need to modify RunCode() to check for nil in the case *Module part of the inModule type check. Does this sound OK?

Activity

1. ncw commented on Oct 23, 2025

   

   ncw

   on Oct 23, 2025

   Collaborator

   More actions

   Your before and after seem to be the same so I'm not sure I understand!

   if mod == nil {
   	mod, err = py.RunFile(context, fpath, py.CompileOpts{UseSysPaths: true}, nil) // Returns a new module
   } else {
   	mod, err = py.RunFile(context, fpath, py.CompileOpts{UseSysPaths: true}, mod) // Adds onto the existing one
   }
   

   Is exactly the same as this isn't it as mod will be nil on first run.

   mod, err = py.RunFile(context, fpath, py.CompileOpts{UseSysPaths: true}, mod) // Returns a new module on first run because 'mod' is nil, adds onto the existing module afterwards
   
2. SolarLune commented on Oct 23, 2025

   

   SolarLune

   on Oct 23, 2025

   Author

   More actions

   Hello - the difference is that I'd like to not call py.RunFile twice, just once. Unless I'm misunderstanding, I have to call it twice currently because passing nil in as an argument to create a new module isn't the same as passing a nil pointer to a *py.Module, as this part of RunCode() switches off of the argument type explicitly:

   gpython/py/run.go

   Line 154 in e20a7a4

   case string:

   So running it with nil for inModule creates a new module, and running it with a pointer to a module for py.Module will update the module, but passing a nil py.Module pointer will cause a crash.
3. drew-512 commented on Nov 10, 2026

   

   drew-512

   on Nov 10, 2026

   Contributor

   More actions

   Confirmed on main (444ae5e): a typed nil *py.Module passed to RunSrc, RunFile or RunCode panics with a nil pointer dereference on mod.Globals, because a nil *Module inside an interface{} matches case *Module, not case nil.

   #260 fixes it the way suggested here: a nil *Module creates a new __main__ module. Its test panics on main and passes on its branch, and the loop from this issue (mod, err = py.RunFile(..., mod)) works with it. It also merges cleanly alongside #258, which touches the same file. #260 shows no CI run yet; GitHub holds workflow runs on a first-time contributor's PR until a maintainer approves them.

Issue actions