Railway Management System
There's nothing that looks bad at a first glance. Couple observations though:

It isn't clear what happens if the time entered isn't in the departure list. Consider adding a default case, even if just to explain to the user that he has to punch in a time present in the list.

A negative number of passengers is valid according to your program, but I doubt this is intentional. Always validate user input.

An exception is thrown if I enter a string instead of a number when asked for the passenger count. See above ;)

At first read, I thought total_seats was, well, the total number of seats but it is the number of seats per coach according to the script output. You might want to clarify that or rename the variable.

You can use \n in your prints to add newlines, I'm not a fan of binding the formatting of your code to the formatting of your output. Both of these lines print the same thing:


print(f&quot;&quot;&quot;Your total price is: {current_passengers*ticket_price} dollars 
&quot;&quot;&quot;)
print(f&quot;&quot;&quot;Your total price is: {current_passengers*ticket_price} dollars \n&quot;&quot;&quot;)


The run variable isn't as self-documenting as it could be if it was named incorrectInput or retryInput or something like that.

Take these two more as suggestions than actual issues with your code:

The fact that your timing system relies on list indexes isn't very pythonic (Explicit is better than implicit). You could use a dict to assign a unique ID to every train... But you'd need a bit more code to reproduce index_train = departure.index(commute), and I'm not a fan of doing syntax gymnastics in &quot;exam code&quot; so I'd say that your solution is good enough.
Another pythonic thing, &quot;Ask forgiveness not permission&quot;: you could get rid of the check for wether commut is in departure, do index_train = departure.index(commute) right away and handle the ValueError that gets thrown if commute isn't in departures using a try except block. Your solution is already fine though (and probably less verbose).

Overall I don't see anything that doesn't work as intended, so it's already pretty solid (as long as the user isn't messing with the input like I did). If it is &quot;exam code&quot; I'd prioritize the formatting and documentation stuff so that your code is more readable. Readable = fast to grade, and fast to grade = less time spend analyzing and figuring out every minor issue with the code ;)