Back in the days of old, one would indeed work and worry about sockets and the down and dirty of network programming. Those days are gone for nearly every modern language - there are easier solutions.
The essence of what you are describing is that of a message queue. These are things that have been built and can be used with rather little additional overhead.
There are two approaches to working with a message queue one to one messages and a publish/subscribe model (often written 'pubsub').
The essence of the one to one is that you connect to the server running a message queue and put a message on the queue, and you're done. Likewise, you can connect to the queue and get a message from the queue.
With a publish/subscribe model you've got something that is pushing messages out to one or more subscribers.
There are many more advanced topics that can be built on top of these with queues forwarding to other queues, or selectively accepting messages, or doing a remote procedure call on another system. The message queue is the underlying framework for a lot of different technologies.
Looking at RabbitMQ (just one of many - there are lots more out there) there is a specific tutorial for a single producer and consumer written in Python (and Java, and Ruby, and Php, and C#) that can be found under their tutorials page.
Pi #2 starts running and connects to the server (who's IP will be static I guess) with a name he chooses. Pi #3 does the same as #2.
Having a static server is indeed the easiest approach. The server is there and you're connecting to it.
However, if you want to go down the 'its not always a static IP address' because your dhcp server isn't cooperating nicely with that, there are technologies for this too.
Realize that I'm saying this in that I've never used RabbitMQ (ActiveMQ? WebSphere? yes... Rabbit, nope - but I've heard good things about it) nor been more than a user of this technology under other names...
Zeroconf. This is one implementation of the technologies that are known as zero configuration networking. The idea is your Pi #1, when it starts up its server would announce to the network "I have this service available!" and everyone else can then use it. It doesn't matter where Pi #1 is located on the network - its there.
This is how some IP cameras work - you look on your local network and you'll see the camera broadcasting its address and a program that can discover it on the network, can do so.
Specifically for RabbitMQ, I've stumbled across this gist which appears to announce to the network that "hey, there's an MQ server here" and now your Pi #1 can show up anywhere on the network and things will work.
Because they always work the first time you deal with a technology Though it may take some additional understanding and delving into this. I wouldn't suggest doing this as a first step - get it working with some message queue server working on a static ip address, and then start seeing about making it broadcast from the static IP address, and then let it grab a dynamic address. Don't go down that particular heh rabbit hole at first.