that's correct.
I see the need to understand the potential and the possibilitiies to apply if appropriate.
Actually, we do this with SQL and it is totally normal  [hopefully]
It should be as normal also for Embedded Py

In past, I have seen so many "re-invented wheels" on COS that were mostly kind of remakes of
existing packages or solutions. Though this is impressive from a coding point of view,
it is just a waste of energy from point of view of a project AND its maintenance.
I had similar experiences with SQL that was refused by "experienced" programmers
insisting on horrible $ORDER() / $QUERY() constructs almost un-supportable, to gain
a few microseconds of performance on a weekly report. 
The deeper reason: nobody explained it and trained them.
That's the behaviour to avoid. 

code sniplet:

set test="CONcatenate".url=""
for i=1:1:$l(test) s url=url_"%"_$zhex($a(test,i)) 

write
i=11
test="CONcatenate"
url="%43%4F%4E%63%61%74%65%6E%61%74%65"

Hi @Vic Sun , @Akshay Pandey :
Just to complete this discussion.
From Terminal I could run Py also from a JOB, and over CPIPE without problems.
From Studio Output all this FAILS.
Which makes clear that the process behind Studio is far away from being a normal
IRIS/Caché process and just good for editing and compiling.  FullStop.
I would even assume that running COS commands was not planned but rather an accident that happened 20 yerars ago.
 

Excellent fit!  

I spent quite a while on the subject of python. Also the asynchronous $ZF(-2) + error log

write $zf(-2,"C:\Users\cemper\AppData\Local\Microsoft\WindowsApps\pythonw3.9.exe <c:\temp\in.py 1>c:\temp\5out.txt 2>c:\temp\5er.txt")

And the error from WINDOWS was always: the program can not be executed
A further reason to use Embedded Python!

in.pyw is simply

print("success")
exit()
 

Just an idea:
I assumed that you use a local installation of IRIS
Is this correct ? 
Or does it run on some instance separate from your local WIN.
whoami is equivalent to echo %USERDOMAIN%\%USERNAME%

write $zf(-1,"hostname > c:\temp\hostname.txt")

may clarify this.
If it's not the same machine you need a PY installation this server

thanks for the clarification.   I had a similar experience with node.js before.
But was not so certain to know the reasoning.

 

this looks like "python" is not recognized in the spawned process
You may try a full reference "C:\......python.exe...."   

In a terminal session you have a process and $ZF(-1) starts a child process
From Studio this is definitely different as Studio uses a different type of connection using SuperServer port.
https://docs.intersystems.com/iris20211/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fzf-1

"know for a fact that is possible to have multiple statements within a single query"
I wasn't aware of such a feature over the decades.
So it might be wise to get in contact with your personal Sales Engineer or contact WRC

So put it in a Stored procedure and deposit the conditions in a table.
Could be a classical case to use indirection or eXecute 
Whether maintaining a table or 70000 different WHERE should be the same effort.
At that point: Why to use SQL DELETE at all ?

I like your PY solution. That's a promising aproach.
Especiallly now with Embedded Py

BUT:   if you intend to have tablename1,  tablename2,  tablename3, ...
you better wrap it in a ClassMethod and  project it as Stored Procedure 

Ah, that's something different.
You require a conversion table by location + a time range when DST is to be applied! 
Location is a static thing to be defined once.
DST is a real challenge as it depends on the region and requires annual adjustment by location.
Including the chance that Europe may split up next year or drop it at all.
It might make sense to get it from an external government source by country.
it is definitely not included in any InterSystems product.   

as by docs.
By default $ztz shows you geographic offset of your server to Greenwich. No DST !
so for Madrid  "write $ZTZ"  => -60

  !!