Starting the terminal client in Python 3 uses a python3 profile by default, so Python 3 commands are kept separate from the main sequence. Starting the Qt console or the HTML notebook, we get the 'default' (i.e. Python 2) profile.
Explicity calling for another profile, e.g. with ipython qtconsole --profile math fails in Python 2.7 as well.
ipython qtconsole --profile math
From your priority rating, I'm assuming we can live with this for 0.12, right? If not, feel free to bump it up and milestone it, though I hope you won't :)
It's not the end of the world, it just means that your input history from Python 2 and 3 get mixed.
I think it should be a simple change somewhere that we're specifying the default profile. I'm having a look, but I can't immediately spot it. Who's most familiar with the Application framework?
app.profile is getting set to Python 3, but it appears it's not being propagated to the shell instance.
Quickly testing, it appears that the same thing happens if I start ipython qtconsole --profile pysh (with any profile name) in Python 2.7. I think this makes it a blocker.
ipython qtconsole --profile pysh
OK, I think I've found it. The terminal frontend initialises TerminalInteractiveShell by explicitly passing it a profile_dir argument. But the IPython kernel doesn't pass the equivalent argument when it instantiates the ZMQInteractiveShell.
I don't know what the best way to deal with this is. The Application, which has the correct profile info, is a layer removed from the Shell (which needs that info) by the Kernel. Do we pass the information through the kernel, or change the profile dir after the shell has been instantiated?
I'm a bit confused by this, because it definitely is not true for me. I can start the qtconsole just fine, and both front and backend share the profile, no matter how or if I set it (python 2.7).
Can you print sys.argv and get_ipython().config in the kernel?
I cannot test the qtconsole with Python 3, because I don't have working pyqt on Python 3.
Side note: I would actually argue that we should remove the different default profile behavior. I imagine that config that is not valid in both is relatively rare, and users with sufficiently complex config that it does conflict, who also regularly use IPython in both py3 and py2 (all 5 of them), should manually specify a different profile when they use IPython with the Python they use less.
I would also rather not have my history separate for the two, because code that is not valid in both is rare, and I would much rather tweak the code that needs small adjustments from my history than retype it all over again.
I think this made sense when py3k support was off in a testing branch, but now that it is in trunk we should stop doing it.
aha! I see what you mean by the shell having the wrong profile. The shell's profile attribute is not updated with the application's value in the zmq case (shell.profile is reported by %profile, not the Application value). I'm not sure that this attribute actually does much anymore, now that it is really an Application-level option, but it is a one-line fix. I'll push in a sec.
The shell really shouldn't need the profile info at all, but since the shell profile does exactly nothing in the zmqshell (as far as I can tell) other than feed the magic that tells you what the profile is, I think we can resolve this with two changes:
self.shell.profile_dir = self.profile_dir
Hmmm, but I think we load the history when the shell is instantiated, so it will attach to the default profile before we set the new profile_dir.
I'm easygoing about whether we should have a separate profile for Python 3. The main difference for interactive use is print(). That's not a problem on a single line, because IPython treats print abc as an autocall. But it could be awkward for statements on multiple lines.
@minrk: Did you get anywhere with fixing the original issue here?
Whoops - I thought you were working on it, but I now see my 'I'll push in a sec' comment. I'll put it together, it's quite simple.
%profile points to application value, not shell value
also add missing shell.profile_dir in ipkernel