This kind of frankensteinism was one of the motivating reasons for creating Julia (see this InfoWorld interview: http://www.infoworld.com/d/application-development/new-julia..., please ignore the misleading title). Python, although it can get you closer to single-language scientific computing, can't quite get you there because of the split language model: at the very least, libraries have to be written in C for adequate performance; often complex projects end up requiring parts written in C.

Doing practical scientific computing only using code implemented in Julia is completely unrealistic. At the very least, a lot of fast kernels (BLAS, LAPACK, etc.) are going to be implemented in C and/or Fortran for the foreseeable future. What Julia brings to the table is the ability to call C/Fortran libraries without writing anything but Julia code — you can just load a .so file and call functions without compiling anything (see http://julialang.org/manual/calling-c-and-fortran-code/). If we could have the same level of trivial interoperability with Python, then you could potentially use scientific libraries written in Python, while still only ever writing Julia code. That helps alleviate the "frankenstein project" problem without throwing out all the excellent work that's been done by the SciPy community.

In the other direction, there are people who already have projects that are all or mostly Python. Forcing them to have some random piece in Julia just to use a nice bit of Julia functionality is making the frankenstein problem worse. If they can trivially call Julia code (perhaps via a .so, as it were just a library written in C), then that's one less frankenstein project in the world.