smart, /g/eeky questions

>>62302845
Are the scripts running concurrently? If so, use IPC.

There's some IPC stuff in the Python standard library:
https://docs.python.org/3/library/ipc.html

If the scripts are not going to be running concurrently, you can use JSON or pickle or text files or whatever you want.

A database such as MariaDB, redis, or sqlite is also an option.

>>62302915

I use MySQL as an "endpoint" for the data.
How would I go around making sure that all of my .py files are running concurrently?

That seems like the easiest option- just run the .py files, then relay the data, no writing/reading from a .txt file needed..

>>62302969
>>62302984
MySQL is ACID compliant so if one of your scripts writes something and the other reads it won't fuck up your data.

It's less "efficient" than a normal ICP method like sockets but it scales better.

"concurrent" just means your scripts run at the same time. If you use a db it doesn't matter if they're concurrent or not.

>>62303086
Interesting. I'm learning a lot of things today. Thank you.

However, I feel like I should clarify a couple of things- my workflow is like this:

first.py --> second.py --> MySQL

>first.py is essnetially a connector/writer to database

So, IPC is the way to go in this case, I guess.
Is there any way for a python script to check if a .py file is running or not?

>>62303372
Sorry, when you brought up MySQL I pictured the following:

MySQL --> first.py --> MySQL
MySQL --> second.py --> MySQL


Is there any reason why you need two separate interpreters? Why not combine the scripts into a single program to be run in a single python instance? Then you wouldn't need to worry about IPC.

If you can't (mixture of python2 and python3?) then yeah your best bet is sockets, shared memory/mmap, or piping one into the other

>>62303555
>>62303372
As for checking if one is open, piping you don't need to worry about (shell takes care of it) and sockets just wait for I/O

>>62303555
>>62303572
Ah, okay. Now piping/socket and shared memory seems like a really good deal.

My idea is that the first.py does a specific purpose, and second.py acts as a middleman. That way, I can interchange first.py with other .py files built for a specific purpose, and second.py would still work- it would just writes to a different column/table.

If that makes sense.

>>62303668
In that case I'd recommend piping.

Have first.py spit out the data in any format you like (such as JSON, csv, or pickle) into stdout

Have second.py read from stdin and write the data to the db.

Then run them like:

$ first.py | second.py

The column/table could be specified in the data or a command line argument to second.py.

If you write it that way, you could swap out first.py with anything, including a bash/powershell script or redirecting to/from a file.

Also you can debug stuff easier that way by sniffing the input with tee:

$ first.py | tee foo.json | second.py
$ cat foo.json

>>62303668
>>62304086
stdin and stdout are just what your script reads/writes to normally (eg. with input/print) btw.

https://docs.python.org/3/library/sys.html#sys.stdin
https://docs.python.org/3/library/sys.html#sys.stdout

File: original-21313-1402070821-13.jpg (77KB, 715x953px) Image search: [Google]

77KB, 715x953px

>>62304086
>>62304133
Oh, man. You're a HUGE helper. I think I have this nailed down now.

I couldn't express my gratitude enough. Here's a picture of a cat receiving a prestigious award..