-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modified ipython banner #8773
modified ipython banner #8773
Conversation
After
I'm +1 on shortening, though this might be a bit short ,and we might want at least a line As this is highly historical, I would like to ping @fperez and @ellisonbg FYI julia prompt (has color):
elixir
|
I am +1 on shortening it as much as possible. On Wed, Aug 26, 2015 at 7:45 AM, Matthias Bussonnier <
Brian E. Granger |
I think it should at least leave one line telling the new user what to type to get more information and how to quit, like the Elixir one, for example. It could be as simple as:
The |
And I'd be curious to hear what others think.. I personally don't find our current banner to be too verbose, actually, and find that I like it more than a one-liner. I'd like to hear a bit more input before we go culling too hard. If I'm the lone holdout I'm not going to oppose some trimming (though I will oppose reducing it to zero), but at least I would like to hear more opinions first. |
On small screen, (understand retina screen divided in 2 vertically). the banner might be a bit big, i wouldn't mind up to 5. One thing that does annoy me is the extra blank line in interactive shell which is 33% less information density : In [1]: 1
Out[1]: 1
In [2]: 2
Out[2]: 2
In [3]: 3
Out[3]: 3
In [4]: 4
Out[4]: 4 >>> 1
1
>>> 2
2
>>> 3
3
>>> 4
4 |
That extra blank line was an early, deliberate decision... It's less information density, but I found many cases where it made for a lot more readable output in more complex cases than the one you're showing. I did put a lot of thought into that, and tested it a lot with my own workflow. But it's configurable, it's a parameter in the prompt classes, and can be removed. |
Yeah, I think the blank line serves a useful visual purpose. |
For the simplification of the banner - this is where usage stats and usability testing would come in useful - otherwise we can only speculate on if users actually find the current banner helpful. |
+1 |
But with out formal data in the usage of the banner does anyone have any anecdotal evidence about the banner from working with users? |
I've enjoyed knowing whether I'm in my default Python or Continuum python when using the console. That bit is helpful (This is the python version bit that no longer exists from this PR). |
My own anecdotal evidence is that, in its current form, it provides relatively minimal but useful information: versions of python and ipython, the banner data for python (the copyright/license stuff for python that I don't think we should drop), and four lines that help beginners get going. And I do use those lines when teaching beginners, to show them how to get started. I tell them: look around, IPython is telling you what to do... Command-line interfaces can be intimidating, and I think it's important not to make them overly hostile to the new user. The expert can always alias |
The extra blank line is one of the unconscious reasons I switched to IPython over the default repl a bajillion years ago now. Regular repl always seemed crowded when I had a lot of output to work with. ❤️ whitespace |
What about
That would include exactly the same information as it currently does, but wouldn't be as bloated as the current one. I understand that line helps beginners and to be honest the banner thing stopped bothering me once I realised I could add It would be nice to ask people who have recently used ipython for the first time for feedback. I remember making an internet search for a doubt I was having instead of using the actual ipython help :P |
Note that the last suggestion throws away the python platform info, which is useful. Knowing that you're running say the Anaconda python vs the system one is often very important:
and I also don't think, as a deference to Python itself, that we should wipe out the Python banner completely:
|
Sorry didn't meant to upset people, I understand the use. It was just my point of view that was nt a request for change. I understand that it help for readability etc... |
No worries, I'm not upset at all, I'm just indicating that there's a very good, well-thought out reasoning behind why IPython's command-line 'look and feel' is the way it is. It may feel a bit 'bloated' to someone, but each and every one of those lines has been thoroughly thought through. It's not the 21 lines of the default R console prompt:
but they are there for a reason. I think we can tighten the info as proposed above into
which will save a few lines, that sounds very good, if people want to go in that direction... But again, people who really want minimalism, should just keep in their
less to type, less to see, less to remember ;) Cheers f |
So,
then? It has exactly the same things but it's less bulky |
Better! I might suggest now shortening to just " 'x?/x??' for object details" to keep the overall line under 80 columns, as it is, it's 85. Replacing Thoughts? |
There, done. To be honest, if all that information has to be in the banner there is nothing else to improve/change/chop off. |
Thanks! As I said, experts can always alias. |
+1, should we merge for a minor release, or is that to be consider only for major ? |
(i've marked as major for now) |
5.0 is fine, thanks! |
), | ||
quick_guide | ||
default_banner_parts = ["Python %s\n"%sys.version.split("\n")[0], | ||
"Type 'copyryight', 'credits' or 'license' for more information\n" , |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copyryight -> copyright
My bad, sorry about that. |
That was quick for a PR that's been waiting months - thanks! :-) I'm not a big fan of how this line has turned out now:
I have looked into shortening the banner before, and concluded there's nothing that can easily be cut. I'll have a play around to see if I can improve on this sentence at all. |
Text mockup
|
No problem! I also think it looks weird now that I see it after all this time. It doesn't bother me personally, but maybe we should ask people who actually see it every time they launch ipython. And as a side note, I'm also interested in knowing if the new users read the help lines and type those things when having trouble or just look their issues up in StackOverflow. Looks like they are there for them and feedback on this would be great. |
This has kinda exploded on my face, hang on a minute while I fix it... |
I honestly can't tell if I've fixed it or not. Would you please mind making sure it's all OK before merging? Sorry about the mess. |
Looking at the diff, I think you've accidentally restored stuff that was recently deleted in master. In general, we recommend rebasing rather than merging master into branches. However, I remain unconvinced about the changes that this is actually trying to introduce. |
Oh, the gui_reference? I thought that deletion was some mistake of the conflict I was trying to solve. I'll update it. About the changes... I don't think I've much say on this. I worked on it after reading the suggestion because it's one of the things I'd have liked to see when I started using ipython. I'm happy with the result but I understand people have strong opinions about it. Just let me know of any further updates to include. And if it turns out to just be a bad idea just close the PR, I'd feel bad if people used too much time arguing about this not-so-important thing when there are other bugs/things to fix. |
object? -> Details about 'object', use 'object??' for extra details. | ||
quick_guide = "Type '?', '%quickref' or 'help' for help, and 'x?/x??' for object details\n" | ||
|
||
gui_note = """\ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bit was deleted in master as well.
My biggest concern with the new text is that it offers the user three completely different options 'for help', when they have no idea which one they want. We either need to differentiate what kind of help they are (which is what the current banner does), or pick just one 'help' resource to point out (which is really hard). |
My 2c to old PR... I'd vote for:
besides one line of version info. Other variants look complicated, and all that info can be presented in introductory section when user types ? |
OK, I'm willing to go with much smaller banner, that looks like this (i.e., down to even removing blank lines). It becomes three lines altogether, the same as the plain python prompt:
But I will only sign off on this IF the If we do that, then I'm OK: the main banner would get much smaller, it would funnel new users into I think that would satisfy what I want to preserve, which is that we need to show something that always helps users at the command line. The argument about the notebook doesn't fully apply here, because given it's a web application, it can have a full-blown help menu and other tools to assist new users. At the cmd line, we need to show some hint of how to get information always, since we can't know in advance if the user is new or experienced. So, if anyone makes the banner as above and does a bit of word-smithing on the |
Thanks @stefanv for the feedback! |
This is a squash of all the commits found in `ipython#8773 - updated banner - updated banner again - fixed type - modified ipython banner - attempt at fixing rebase issues - modified ipython banner - fixed git screwup - updated banner - updated banner again - fixed type - fixed accidental deleted gui_reference restoration
Merged in #9912 , Thanks all for the hard work and apology for a PR to have taken that long to be merged ! |
Modified the ipython banner, as suggested in issue #4556
I've opted for the format
IPython <version> (Python <version>) -- An enhanced Interactive Python.
since I got no feedback in the issue page and seemed like the cleanest way. This can be updated easily by changing the default_banner_parts variable inIPython/core/usage.py
.