I do this as a PR rather than pushing straight, because we need to make a small decision.
The Start Menu item we create for pylab mode with the Windows previously loaded the pylab profile , rather than using --pylab (it had a typo preventing it from working at all, hence the PR). This conflicts with the fact that the pylab profile we ship seems meant as an example for non-standard pylab init, and really expects to be edited. For instance, it explicitly sets qt, ignoring matplotlib config, and does not use %pylab, in favor of %gui qt and some custom imports.
We should decide whether it should use --pylab or --profile=pylab. I would lean towards the former, but if we go with the latter, we must change the pylab profile to no longer be an example of weird config, but an example of simple/common config.
fix pylab StartMenu item
remove pylab profile
pinging @fperez, based on his reply on-list. We previously shipped a pylab profile, which set the backend to Qt, among other things, and showed an example of inheriting config from the default profile. In this PR, I've removed the profile, and changed the Start Menu item to use the default profile. Does that sound good? Another option would be for the Start Menu item to still load --profile=pylab, even if that doesn't exist. This would allow users to have separate config triggered by each menu item, which not be enabled in the current state of the PR.
If config is inherited, the most obvious effect of using a separate profile is a separate history. On the one hand, it's quite natural to have a separate history for pylab, because you're using a lot of names that aren't present in the default IPython shell. On the other hand, a unified history is possibly the 'least surprise' option, and is handy if you want to take code from non-pylab to pylab.
I'm currently mildly in favour of using the default profile (the current state of the PR), but I've flip flopped twice in writing this comment.
I agree that it's great to have a separate profile to distinguish the histories, but we should go for simplicity and generality. I think the cleanest solution is to go with --pylab, nuke the weird pylab profile, and then simply have a clean explanation of how to create a profile that inherits from another, along with explaining how this impacts history. This gives the benefits of these ideas to anyone (not just those using pylab), and makes the out-of-the-box behavior simpler and closer to what people do in the command-line (where they've learned to type ipython --pylab from countless tutorials).
In summary, +1 to the PR as it stands, and bonus points for a little blurb in the docs explaining config inheritance with a .. note:: box for the fact that history is per-profile. I don't think we need anything else here.
The docs already mention that history is per-profile, and show config file inheritance, so I'll merge this as-is.
Agreed, there's enough already in there. Thanks!