Dive into the world of machine learning on the Databricks platform. Explore discussions on algorithms, model training, deployment, and more. Connect with ML enthusiasts and experts.
I actually managed to fix it by rolling back my databricks runtime and adding a pinned install of `plum-dispatch` (apparently some people in my team had previously had this issue and found a fix, but it's something that periodically happens).
DBR 17.3 and `plum-dispatch==2.7.0` worked for me.
As a side note, @GuyBourne 's response above is very similar to what I got when I asked Copilot about the error. It would be really helpful if people indicated when they used AI to assist in their answer.
This error pattern, 'Function' object attribute '__doc__' is read-only, is a known upstream issue in fastcore related to how it monkey-patches Python built-in function objects. Thefastcorelibrary attempts to set__doc__on built-inFunction(C-level) objects, which CPython does not allow. This can surface when:
Aminor CPython patchis included in the new runtime (e.g., 3.12.x → 3.12.y), tightening attribute-setting behaviour on built-in types.
Adifferent library versionin the runtime environment changes the import order or triggers a different code path in fastcore's initialisation.
Since you confirmed the only visible change is the runtime release (18.3.5 → 18.3.6), a CPython micro-version bump or a change in a transitive dependency is the most probable trigger.
Recommended next steps
Check the Python micro-version: Runimport sys; print(sys.version)on both 18.3.5 and 18.3.6 clusters to confirm whether the CPython patch level changed.
Pin to a working runtime: If you need an immediate fix, pin your cluster to 18.3.5 while investigating.
Check fastcore's GitHub issues: Thefastcore issue trackerhas had similar__doc__read-only reports tied to specific Python versions.
File a support ticket: Since this appears to be a regression introduced by the 18.3.6 maintenance release, filing a Databricks support ticket referencing the runtime change would help the Runtime team investigate whether a CPython or dependency change is responsible.
Thank you for the reply Guy, I'm not actually sure whether the change is down to runtime version now - I've tried importing from fastai using various runtimes (18.2.9, 17.3.20, 19.6.3), using a node with or without GPU, and using an ML and a non-ML runtime.
Also, I couldn't find any other issues with the same problem with setting __doc__ on read-only built-in types in the fastcore issue tracker. If you found any, would you mind linking to them?
Thanks for pointing to that issue, but I'm really not sure it's related to this error?
I pinned the fastai version to 2.8.5, which was the version that worked yesterday, and tried different runtimes. It didn't work for any of them, so not sure what the problem is here.
I’m seeing the same issue today—seems like the recent compute runtime update may be related. Hopefully someone from the fastai/Databricks side can confirm.
I actually managed to fix it by rolling back my databricks runtime and adding a pinned install of `plum-dispatch` (apparently some people in my team had previously had this issue and found a fix, but it's something that periodically happens).
DBR 17.3 and `plum-dispatch==2.7.0` worked for me.
As a side note, @GuyBourne 's response above is very similar to what I got when I asked Copilot about the error. It would be really helpful if people indicated when they used AI to assist in their answer.
Hi @barnabywalker, glad you found a fix whilst the versions are out of sync.
I've run into the fastcore / CPython issue a few times before, so I was surprised that pinning it on the older runtime didn't resolve it.
And yes, I did use an AI assistant to help shape the response. Fair feedback on making that explicit, I’ll include a note when I’ve used AI to assist in future answers.
