On 2021-01-01 at 11:11:47 +0100, jak <nos...@please.ty> wrote: > Il 01/01/2021 04:14, 2qdxy4rzwzuui...@potatochowder.com ha scritto: > > On 2021-01-01 at 03:43:43 +0100, > > jak <nos...@please.ty> wrote: > > > > I think you were clear enough before, but you may not have > > considered things the OP did not specify. One of the hardest parts > > of software development is understanding and specifying the actual > > problem to be solved. I've never done that in a second language > > (I'm nowhere near fluent in anything other than English); I can only > > imagine the extra layers of complexity. > > This is the OP's initial request: > > > Hi. I would like to make something like this: > > A python script would run headlessly in the background. > > I would like to control the script from the command line using other python > > scripts or from the python shell. > > From time to time I would ask the main script to create a popup window with > > an image or a plot. > > What would be the proper way to approach it. How to make communication > > between two scripts? > > Thank you. > > Petro. > > I have suggested an alternative way for his necessity. > It will be up to him to decide which one he should adopt. That way he > has a choice, at least. > I don't know where you work. I know, however, that in these zones, if > you do more than necessary wasting their time, they will kick you away.
So what is necessary? Does "control the script" include reporting success or failure of a request? The OP also said "communication between two scripts," which to me means two way traffic. Only the OP knows for sure, and at least one of us might get it wrong if we don't ask, or at least acknowledge that we don't know. If I start with a named pipe because it's good enough for Phase Zero, or Version 0.0.1, or Release Experimental Alpha, then I'm going to end up ripping that out or reinventing something that already existed on top of that named pipe. Suppose I look ahead just a little, and use a socket in the first place. Yes, you could argue that it's more than what was necessary and kick me away. Will you kick me again when you can build on it (I can't; I'm gone) instead of having to rebuild what already worked? I'm retired now, but I at one employer, I worked on products with (a) lifetimes measured in decades, (b) extremely expensive (money, time, convenience, etc.) upgrade/maintenance cycles, and therefore (c) strict interoperability requirements.¹ A little bit of foresight and extra analysis up front went a long way towards saving a lot of headaches and development resources (and customers!) in the long term. Communications protocols in particular had to be well thought out, and often more complex than was immediately necessary, because backwards and forwards compatibility were not negotiable. Again, I'm not (and no one else is, either) saying that your solution is wrong or won't work. Your solution may even be the be the best solution to the OP's problem. All I'm saying is that we can't know until the OP tells us more. Yes, the OP has a choice to make. Maybe we have helped, not by making that choice, but by giving it to the OP with enough supporting information to make it. ¹ Think about a system containing dozens of individually field upgradeable components. It had to work when a customer upgraded one component at a time (over the course of weeks or months), or plugged in an old component while they were waiting for a broken one to be repaired, or added a brand new component to a system that hadn't been changed or upgraded for years. There was no such thing as telling the customer to wait, or to make them take down the entire system to upgrade everything at once. *That* was what was necessary. -- https://mail.python.org/mailman/listinfo/python-list