Background: I'm a data scientist at a startup in Austin, and I come from grad school (Physics). I use Python day-to-day for data analysis, but use R a bit. I also use C#/.NET and Java (just about daily), I used C++ heavily in grad school.
I think the main problem with using Python for numerics (over R) is the size of the user community. Since the language has been around for ever, lots of people have done things that you're likely to want to do. This means that, when faced with a hard problem, you can just download the package and get to work. And R "just works": you give it a dataset, and it knows what summary statistics are useful. You give it some results, and it knows what plots you want. All the common plots you'd want to make are there, even some pretty esoteric ones that you'll have to look up on Wikipedia. As nice as scipy/numpy/pandas/statsmodels/etc. are for Python, they're not at the level of the R standard library.
The main advantage of Python over R is that it's a real programming language in the C family. It scales easily, so it's conceivable that anything you have in your sandbox can be used in production. Python has Object Orientation baked in, as opposed to R where it feels like kind of an afterthought (because it is). There's other stuff that Python does nicely too: threading and parallel processing are pretty easy, and I'm not sure if that's the case in R. And learning Python gives you a powerful scripting tool, too. There are also really good (free) IDEs for Python, much better ones if you're willing to pay (less than $100), and I'm not sure this is the case for R--the only R IDE I know of is R Studio, which is pretty good, but isn't as good as PyDev + Eclipse, in my experience.
I'll add this as a bit of a kicker: since you're still in school, you should think about jobs. You'll find more job postings for highly skilled Python devs than you will for highly skilled R devs. In Austin, jobs for Django devs are kind of falling out of the sky. If you know R really well, there are a few places where you'll be able to capitalize that skill (Revolution Analytics, for example), but lots of shops seem to use Python. Even in the field of data analysis/data science, more people seem to be turning to Python.
And don't underestimate that you may work with/for people who only know (say) Java. Those people will be able to read your Python code pretty easily. This won't necessarily be the case if you do all of your work in R. (This comes from experience.)
Finally, this may sound superficial, but I think the Python documentation and naming conventions (which are religiously adhered to, it turns out) is a lot nicer than the utilitarian R doc. This will be hotly debated, I'm sure, but the emphasis in Python is readability. That means that arguments to Python functions have names that you can read, and that mean something. In R, argument names are often truncated---I've found this less true in Python. This may sound pedantic, but it drives me nuts to write things like 'xlab' when you could just as easily name an argument 'x_label' (just one example)---this has a huge effect when you're trying to learn a new module/package API. Reading R doc is like reading Linux man pages---if that's what floats your boat, then more power to you. When I have a question about how something works in R, I avoid the R documentation, whereas I START with the Python doc when I'm confused about Python.
All of that being said, I'd suggest the following (which is also my typical workflow): since you know Python, use that as your first tool. When you find Python lacking, learn enough R to do what you want, and then either:
- Write scripts in R and run them from Python using the subprocess module, or
- Install the RPy module.
Use Python for what Python is good at and fill in the gaps with one of the above. This is my normal workflow---I usually use R for plotting things, and Python for the heavy lifting.
So to sum up: because of Python's emphasis on readability (search gooogle for "Pythonic"), the availability of good, free IDEs, the fact that it's in the C family of languages, the greater possibility that you'll be able to capitalize the skillset, and the all-around better documentation-style of the language, I'd suggest making Python your go-to, and relying on R only when necessary.
Ok, this is (by far) my most popular answer ever on a stack site, and it's not even #1 :) I hope this has helped a few people along the path.
At any rate, I've come to the following conclusion after several years in the field:
This is probably the wrong question to ask.
Asking "should I learn this particular technology" is a bad question. Why?
- Technology changes. You'll always have to learn another technology. If you go work at Twitter, they run Scala. Some places are Python shops. Some places don't care. You're not going to be hired because you know or don't know some particular piece of tech--if you can't learn a new tech, you can (and should be) fired. It's like, if a new pipe wrench comes out, and you're a plumber, and you can't figure out how the new pipe wrench works, you're probably a pretty lousy plumber.
- Given the choice of "Do I learn this technology" or "Do I spend more time solving real problems", you should always choose the latter, without exception.
As a data scientist, your job is to solve problems. That single bit of wisdom is pretty much always lost at every conference or meetup you go to--every "big data" talk I've ever seen has focused on tech, not on solving problems. The actual problem solving is usually relegated to a few slides at the end:
[Talk title = "Deep learning at Cool New Startup"]...[45 minutes of diagrams and techno-babel during which I zone out and check my phone]...And, after implementing our Hadoop cluster and [Ben zones out again] we can run our deep learning routine, [wake up: this is why I came!] the details of which are proprietary. Questions?
This gives a bad impression that the field is about tech, and it's just not true. If you're really good at Scala, or Python, or R, but you're really bad at solving problems you will make a lousy data scientist.
Paco Nathan was in Austin a few months ago at a day long "big data" conference, and said something like "Chemistry isn't about test tubes". That pretty much sums it up--data science isn't about Scala, or Hadoop, or Spark, or whatever-other-tech-du-jour pops up. At the end of the day, I want to hire people who think, not people who are adept at using Stack Overflow to learn toolkits.
Likewise, if you go to a job interview, and they don't hire you just because you don't know some programming language, then that company sucks. They don't understand what "data scientist" means, and it's probably better for you if it didn't work out.
Finally, if your problem solving abilities are marginal (be honest with yourself), or you really just enjoy the tech side of things, or learning tech is what you really love (again, be honest) then learn a lot of tech. You'll always be able to find "data engineer" type roles that fit your skill set. This isn't a bad thing, data engineers grease the wheels and make it possible for you to do your job as a data scientist. (The difference is akin to software architect vs. the development team.)