Catalina introduced a new feature that overlaps and reinforces the filesystem protections that SIP provides. What it does is split the files between two volumes: a system volume containing Apple-provided system files, and a "data" volume containing all non-Apple and modifiable files. The system volume is mounted read-only as / (the root filesystem), and the data volume is mounted with read-write access as /System/Volumes/Data. There are also "firmlinks" that merge the content from the data volume in where it "belongs" (e.g. /System/Volumes/Data/Users shows up in /Users). If you change something in a firmlinked directory, the changes are stored on the data volume. If you try to change something in a non-firmlinked directory, it'll fail because it's on a read-only volume (even if SIP is completely disabled).
For more details, see the Ars Technica review of Catalina, the WWDC2019 sesson "What's New in Apple File Systems", and a filesystem map from the Eclectic Light Company.
If you really need to make changes in the content on the read-only system volume, it is possible, but I'd recommend against it if there's an alternative. Most of the things you normally want to change/add/etc can be done from modifiable parts of the filesystem (e.g. using /usr/local instead of /usr). So the rest of this comes with a warning.
Warning: I have not tested this much, and make no promises at all about what the consequences will be (including both immediate consequences, and what happens the next time an OS update changes things). Do you have any important files on this Mac? Do you have a good backup? Do you feel lucky?
[Update: In Big Sur, the system volume is not just read-only, but also signed, so changing it is even more difficult. See "Mount root as writable in Big Sur" for more info.]
To make changes to the normally-read-only volume, you need to both disable SIP's filesystem protection and also re-mount the volume with read access:
Restart in Recovery mode (Command-R at startup), open Terminal (from the Utilities menu), and disable SIP filesystem protection with:
csrutil enable --without fs
Restart normally, open Terminal, and remount the root volume for read access:
sudo mount -uw /
At this point, you should be able to make changes everywhere (subject to normal filesystem protections) up until the next restart. Disabling SIP's filesystem protection survives restarts, but remounting with write access does not. If you want everything to be writable after restarting, you'll have to repeat the sudo mount command after each restart. What I'd recommend, though, is locking everything back down as soon as you've made the necessary changes. To do this, restart in Recovery mode, run csrutil enable, then restart again normally.
Research led to the macOS tccutil, which in turn led to tccplus, a generously thorough implementation of the undocumented capabilities of tccutil, which provides the ability to manage the privacy database directly.
Best Answer
The problems observed are related to the new system policy for user owned "system folders" like Documents, Desktop etc.
Here is a related syslog entry me trying to execute or open some script/file in $USER/Documents/ with Spyder/iPython:
I had no problems to execute scripts in subfolders of Documents though.
One may add an executable to System Preferences > Security & Privacy > Privacy > Full disk access (see this q&a), but since too many execs may be involved, it's much simpler to create a new folder (e.g Development, Dev, Anaconda-Dev etc.) in your user folder and move your dev files & folders in there. The permission errors should disappear afterwards.