Skip to content
This repository

ZMQShell always uses default profile #939

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

3 participants

Thomas Kluyver Min RK Fernando Perez
Thomas Kluyver
Collaborator

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.

Fernando Perez
Owner

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

Thomas Kluyver
Collaborator

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?

Fernando Perez
Owner
Thomas Kluyver
Collaborator

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

Thomas Kluyver
Collaborator

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.

Thomas Kluyver
Collaborator

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?

Min RK
Owner

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.

Min RK
Owner

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.

Min RK
Owner

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.
Thomas Kluyver
Collaborator

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.

Fernando Perez
Owner
Thomas Kluyver
Collaborator

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

Min RK
Owner

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.

Min RK minrk referenced this issue from a commit November 01, 2011
Commit has since been removed from the repository and is no longer available.
Min RK minrk referenced this issue from a commit November 01, 2011
Commit has since been removed from the repository and is no longer available.
Min RK minrk referenced this issue in takluyver/ipython November 01, 2011
Merged

Default profile #3

Min RK minrk referenced this issue from a commit in minrk/ipython November 01, 2011
Min RK %profile points to application value, not shell value
also add missing shell.profile_dir in ipkernel

closes gh-939
020c172
Min RK minrk closed this in c3d885f November 02, 2011
Brian E. Granger ellisonbg referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Brian E. Granger ellisonbg referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.