You're close.

...
volumes:
  - ./:/data
...
working_dir:  /data

That will mount your CWD to /data inside the container and then set the working directory inside to that.

Even if ./:./worked you want to be explicit with your container directories. . refers to the current directory and that will change based on what you define as your working directory or whatever the base image uses as a working directory. In other words, it's kind of brittle.

If the script is working like that it implies that your working_dir is / inside the container, hence why your python script can write to ./data instead needing to say of /data with the absolute forward slash. To my knowledge volumes cannot be mounted that way because the working directory inside the container is constantly changing, but you can set the initial working directory to /data. If you don't want the python script inside the data folder/working directory but still want to be able to call it without specifying a path to the script you'll need to copy it into a bin folder. So in summary you would have the script in bin, your working directory would be /data which would be associated with your machine's directory you used when starting the docker-compose and the script would just use the path ./

Edit: another option if you can't change the starting working directory is simply to cd first: cd /data && yourscript

You've pretty much answered it yourself in the example you gave: you can mount the host's relative path ./ to an absolute path /data in the compose file, and the container will mount the $CWD at launch as /data.

I think most bind mounts are default read-only, which is why your write is failing. Try adding ,rw to the end of the list entry in volumes and see if that helps.

edit: another poster got it with working_dir which also is more right

Using relative paths is bad practice, by the way. It's fine for development and testing, but in production you would want always to use absolute paths. Think of it as a bad habit that leaves surprises for yourself and othere down the road when moving or replicating projects. If you want it to be more dynamic, consider using compose vars and environment variables

Another thing you might want to consider is not mounting the project root as a RW filesystem in your containers, since this allows the container to modify its own compose file. That's rarely something you'd want to do. Better to make a subdirectory for each container in the project folder, and mount those into the appropriate contains