ZMQShell always uses default profile #939

Closed
takluyver opened this Issue Oct 28, 2011 · 13 comments

Projects

None yet

3 participants

@takluyver
Member

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.

@fperez
Member
fperez commented Oct 28, 2011

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 :)

@takluyver
Member

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?

@fperez
Member
fperez commented Oct 28, 2011

On Fri, Oct 28, 2011 at 1:05 PM, Thomas
reply@reply.github.com
wrote:

Who's most familiar with the Application framework?

@minrk, I think.

@takluyver
Member

app.profile is getting set to Python 3, but it appears it's not being propagated to the shell instance.

@takluyver
Member

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.

@takluyver
Member

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?

@minrk
Member
minrk commented Oct 28, 2011

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.

@minrk
Member
minrk commented Oct 28, 2011

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.

@minrk
Member
minrk commented Oct 28, 2011

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:

  1. add self.shell.profile_dir = self.profile_dir in IPKernelApp.init_shell()
  2. change magic_profile to query BaseIPythonApplication.instance() (error message if not initialized), instead of the shell object.
@takluyver
Member

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.

@fperez
Member
fperez commented Oct 28, 2011

On Fri, Oct 28, 2011 at 2:54 PM, Thomas reply@reply.github.com wrote:

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.

I'm with Min on this one: I'd rather have the same history in both.

Esp. b/c once I start using py3 for real, I'll add to my config from __future__ import print_function to have consistency on the print usage...

@takluyver
Member

@minrk: Did you get anywhere with fixing the original issue here?

@minrk
Member
minrk commented Nov 1, 2011

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.

@minrk minrk referenced this issue in takluyver/ipython Nov 1, 2011
Merged

Default profile #3

@minrk minrk added a commit to minrk/ipython that referenced this issue Nov 1, 2011
@minrk minrk %profile points to application value, not shell value
also add missing shell.profile_dir in ipkernel

closes gh-939
020c172
@minrk minrk closed this in c3d885f Nov 2, 2011
@mattvonrocketstein mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014
@minrk minrk %profile points to application value, not shell value
also add missing shell.profile_dir in ipkernel

closes gh-939
e294574
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment