I don't think it makes sense to go out of our way to make a standard python lib import optional. It's an anti-pattern to import things inside functions.

I agree it's an anti-pattern, but I think it certainly makes sense here because with a pretty simple change we enable PyMC in the browser. So I think the added tech debt is worth it. We can also make it optional if we're running on pyodide.

We can also make it optional if we're running on pyodide.

How does that look like?

That's even uglier

So what do we do?

Local import or nothing. Should an issue be open with pyodide as well?

OK, I don't mind which way. What issue would that be?

OK, I don't mind which way. What issue would that be?

Shouldn't pyodide support the python standard library?

Shouldn't pyodide support the python standard library?

I don't think it's an oversight, they just haven't figured out multiprocessing yet.

Looking at this from the PyData NYC sprint. I don't really see how we could unblock this given that multiprocessing is used in various other modules in PyMC. Would we make the import local to all of the modules that use it??

Where else is it being used? I guess that'd be the only way then, depends in how many modules we use it.

Hi, I’d love to work on this issue as my first contribution. Is it still available?

Yes!

Hi @twiecki @ricardoV94,

Updated PR #7736 to fix #7519 by moving multiprocessing import to run_chains. Also enhanced test_mcbackend.py.

Local tests failed (CompileError), Colab passed test_censored.py. Fixing MinGW next.

Thanks,
Atul Boyal

Hi @twiecki @ricardoV94,

I’m 17 until June 30, missing GSoC 2025 registration (ends April 8). PR #7736 is in, and I fixed test_censored.py locally with 64-bit MinGW (all tests pass now). I’d love to keep working on PyTensor compilation fixes for Windows—any chance for unofficial mentorship this summer?

Thanks,
Atul Boyal
(AnInnovativeCoder)

I have found a bit of a hack on my marimo WASM notebook.

import sys
sys.modules['_multiprocessing'] = object
from multiprocessing.pool import ThreadPool

This seems to get past the multiprocessing bug, but I seem to hit another issue down the line.

with Model() as model:  # model specifications in PyMC are wrapped in a with-statement
    # Define priors
    sigma = HalfCauchy("sigma", beta=10)
    intercept = Normal("Intercept", 0, sigma=20)
    slope = Normal("slope", 0, sigma=20)

    # Define likelihood
    likelihood = Normal("y", mu=intercept + slope * x, sigma=sigma, observed=y)

    # Inference!
    # draw 3000 posterior samples using NUTS sampling
    idata = sample(3000, cores=1, nuts_sampler="nutpie")

This yields:

Traceback (most recent call last):
  File "/lib/python3.12/site-packages/marimo/_runtime/executor.py", line 141, in execute_cell
    exec(cell.body, glbls)
  Cell marimo://notebook.py#cell=cell-7, line 12, in <module>
    idata = sample(3000, cores=1, nuts_sampler="nutpie")
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lib/python3.12/site-packages/pymc/sampling/mcmc.py", line 789, in sample
    provided_steps, selected_steps = assign_step_methods(model, step, methods=pm.STEP_METHODS)
                                                                              ^^^^^^^^^^^^^^^
AttributeError: module 'pymc' has no attribute 'STEP_METHODS'

Figured I'd mention it in case it might be something that's also caused by pyodide.

Yeah, nutpie won't work on wasm.