A formal definition for the term "pythonic" would be largely impossible.
It's as impossible as a definition for "aesthetic" or "convenient" or "delightful".
It can't be less subjective than it is now.
Why not?
Because Python is merely as aesthetic judgement based on the opinions of a fairly large number of people. The GvR points are respected, but do not have the force of law. Many people write code for the Python world, and their various inputs influence other developers. It's a vast social network of people all liking (and disliking) the code they read.
Ultimately I would like to get closer to more logical or mathematical interpretation of the matter
You would do well to start with studying art, aesthetics and philosophy first. Then, after mastering aesthetics and morals, switch to ontology so that you can encode what you learned about truth and beauty. Once you've finished that, you'll have a formal definition of Pythonic along with formal definitions of all the various subjective values that we hold.
axioms ... built/reformulated from "Zen of python"
It's a poem. It's value is entirely aesthetic. What more evidence does one need that Pythonic is a value judgement based on depth of experience?
This question is basically two-fold:
- How do you solve the actual problem? and
- How do you generally read in graph data?
The first question is a bit narrow, and it sounds like the second one is of more interest to you in the long run. So, let me just point you to flow algorithms. It's a step up from Dijkstra in terms of implementation complexity, but as you already realized, there is just so much you can do with a single path. Network flows are a whole different thing.
As for reading your input, it dramatically depends on the kind of graph library you want to use. A few years ago, when I was active in these competitions, we weren't allowed to use 3rd-party libraries, so had to roll our own implementations.
In that case, you have to think ahead if you want to read in a complete matrix, or if you want to keep the graph as an adjacency list. These are the two most important data structures to know for graph algorithms. (more precisely, often you don't need to think ahead, because the problem input specification directs you to one or the other)
Reading input for an adjacency matrix is as straightforward as two nested for-loops. In the body of the inner loop, you simply read one value and assign it to one matrix cell. Done.
For adjacency lists you need to prepare the list of neighbors of a node for each of the nodes, i.e. for n nodes you prepare a list of size n that contains an empty list for each entry. Then you again have two nested for-loops: the outer loop goes over the nodes, the inner loop reads the neighbors of that node and adds them to the corresponding inner list. Voila - an adjacency list representation of the graph.
Important addition for programming challenges/competitions: Make sure that you know in your dreams how to write both variants before you even think about competing. There are limitless sample questions and practice sites out there. Search around for problems with graph input, then write and rewrite the input code again and again. It should almost always be nearly the same code, and once you've grown accustomed to it, reading in input like the one you gave above takes you 5 minutes at most. If you want to compete with the really strong players in that field, you should be able to code the input reading for this within about 1 minute or less.
Best Answer
Obviously, if you consider this question in the context of something like Google Code Jam, then algorithmic thinking is clearly more important when having to solve algorithmic problems.
In everyday life, however, about a million other factors have to be considered as well, which makes the question much less black vs white.
Just a counter-example: If you need 200 more lines in Java, but everyone in your company knows Java, this isn't a big deal. If you could write it in 5 lines of Python or any other language, but you would be the only one in the company to know that language - it is a big deal. Such big a deal in fact, that you will not even be allowed to do so and instead have to write it in Java.
From a craftman's perspective, we always try to approach with the right tool for the job, but the word right in there is so tricky that one can easily get it wrong.
On the contrary, I found algorithmic thinking in companies to be almost absent. Only few select people possess it, whereas the average joe often already has troubles estimating runtime complexities of loops, searches, etc.
In terms of algorithmic competitions, however, my personal experience from competing in them for several years, clearly tells me that you should stick to one language. Speed is a major factor and you simply cannot afford to waste time on your tools, when you should dedicate it to solving the problems within the time limit. Also consider that writing 200 lines of Java code without thinking is still much faster than hand-crafting 50 lines of complicated python code requiring a lot of thinking, yet both solving more or less the same problem.
Oh and finally, make sure you understand the major differences between algorithmic competition code and company production code. I have seen fantastic algorithmic coders, that wrote horrible code I would not ever accept in a product.