Ease of learning
Python and Fortran are both relatively easy-to-learn languages. It's probably easier to find good Python learning materials than good Fortran learning materials because Python is used more widely, and Fortran is currently considered a "specialty" language for numerical computing.
I believe the transition from Python to Fortran would be easier. Python is an interpreted language, so the number of steps it takes to get your first program running is smaller (open the interpreter, type
print("Hello, world!") at the prompt) than it is for Fortran (write a "Hello world" program, compile, run). I also think that there are better materials to teach object-oriented style in Python than in Fortran, and there's more Python code available on GitHub than Fortran code.
Getting up and running on Windows
Installing Python should be less painful; there are Windows distributions available. I recommend using a scientific distribution like Anaconda or Enthought Canopy. There's not really a compiler, per se; the interpreter takes that role. You'll want to use a CPython-based interpreter, because there are more numerical libraries available and it interoperates nicely with C, C++, and Fortran. Other interpreter implementations include Jython and PyPy.
On a Windows machine, installing a Fortran compiler is going to be annoying. Typical command-line compilers are programs like gfortran, ifort (from Intel; free for personal use, otherwise costs money), and pgfortran (from PGI; free trial versions, otherwise costs money). To install these compilers, you might need to install some sort of UNIX/POSIX-type compatibility layer, like Cygwin or MinGW. I found it a pain to work with, but some people like that workflow. You could also install a compiler with a GUI, like Visual Fortran (again, you'd have to pay for a license). Windows Subsystem for Linux (WSL) could also be used to install gfortran compiler in Windows.
On Linux, it will be easier to install Python and compilers; I would still install Anaconda or Enthought Canopy as a Python distribution.
Speed: a productivity vs. performance tradeoff
In using Python (or MATLAB, Mathematica, Maple, or any interpreted language), you give up performance for productivity. Compared to Fortran (or C++, C, or any other compiled language), you will write fewer lines of code to accomplish the same task, which generally means it will take you less time to get a working solution.
The effective performance penalty for using Python varies, and is mitigated by delegating computationally intensive tasks to compiled languages. MATLAB does something similar. When you do a matrix multiplication in MATLAB, it calls BLAS; the performance penalty is virtually zero, and you didn't have to write any Fortran, C, or C++ to get the high performance. A similar situation exists in Python. If you can use libraries (for example, NumPy, SciPy, petsc4py, dolfin from FEniCS, PyClaw), you can write all of your code in Python and get good performance (a penalty of maybe 10-40%) because all of the computationally intensive parts are calls to fast compiled language libraries. However, if you were to write everything in pure Python, the performance penalty would be a factor of 100-1000x. So if you wanted to use Python and had to include a custom, computationally intensive routine, you would be better off writing that part in a compiled language like C, C++, or Fortran, then wrapping it with a Python interface. There are libraries that facilitate this process (like Cython and f2py), and tutorials to help you; it is generally not onerous.
Scope of use
Python is used more widely overall as a general-purpose language. Fortran is largely limited to numerical and scientific computing, and is mainly competing with C and C++ for users in that domain.
In computational science, Python typically doesn't compete directly with compiled languages due to the performance penalties I mentioned. You would use Python for cases where you want high productivity and performance is a secondary consideration, such as in prototyping numerically intensive algorithms, data processing, and visualization. You would use Fortran (or another compiled language) when you have a good idea of what your algorithm and application design should be, you're willing to spend more time writing and debugging your code, and performance is paramount. (For instance, performance is a limiting step in your simulation process, or it is a key deliverable in your research.) A common strategy is to mix Python and a compiled language (usually C or C++, but Fortran has been used also), and only use the compiled language for the most performance-sensitive parts of the code; the development cost is, of course, that it's harder to write and debug a program in two languages than a program in a single language.
In terms of parallelism, the current MPI standard (MPI-3) has native Fortran and C bindings. The MPI-2 standard had native C++ bindings, but MPI-3 does not, and you would have to use the C bindings. Third-party MPI bindings exist, such as mpi4py. I've used mpi4py; it works well, and is straightforward to use. For large-scale parallelism (tens of thousands of cores), you'd probably want to use a compiled language because things like dynamically loading the Python modules will bite you in the ass at scale if you do it in a naïve way. There are ways to get around that bottleneck, as demonstrated by the PyClaw developers, but it's simpler to avoid it.
I have roughly a decade of experience in Fortran 90/95, and I've also programmed in Fortran 2003. I have roughly five years of experience programming in Python. I use Python much more than I use Fortran because, frankly, I get more done in Python. The majority of the work I need to do does not require major supercomputing resources and is generally not worth re-developing in another language, so Python is just fine for solving ODEs and PDEs. If I need to use a compiled language, I will use C, C++, or Fortran, in that order.
Most of the Fortran code I've seen has been ugly, mainly because most of the computational science community seems unaware of or averse to any best practices discovered by software engineers in the last 30 years. To wit: there is no good unit testing framework in Fortran. (The best I came across is FUnit, by NASA, and that's not maintained anymore.) There are a few good Python unit testing frameworks, good Python documentation generators, and generally many better examples of good programming practices.