Not "for" but **with**.

Ideally of course, and assuming you can find the time.  

I've supervised experimental projects in which a similar amount of Python is an important part.  The students have encountered Python before, but mainly analysing/plotting data in a fairly limited context, while for my project hardware interfacing and flow control were more important.  I provided the simplest possible readout function to avoid them getting stuck on a very steep bit of learning curve.  The Python part of the project was clear up front.

Some students needed no help.  Many of these had additional prior programming experience, but by no means all.

Most needed a little guidance - I could give them pointers and they could debug.

A tiny minority could have been considered lost causes, but that was because of failure to engage with the support they were offered.

The ones of interest here had the capability to debug their code, but had never done so.  So they needed help to get from "My code doesn't work", through defining working/not working, examining error messages and output, checking execution flow and intermediate variables, and on to correcting the code.

As far as I was concerned, debugging *experiments*\* was a key learning outcome of the project; the code was part of that.  And, here at least, the point of the project is that to go with more independence, they have more targetted support.

---

\*<sub> For example, a couple of times they got strange results caused by sunlight reflecting off another building, through a small gap, and into the photodiode they were using.  It was only then that they understood my insistence on logging against wall-clock time, not elapsed time (which tended to drift as they started with the implicit assumption that `time.sleep (30)` in a loop meant the loop executed once every 30 seconds)</sub>