The python IDE, IDLE, currently has the “Show Line Numbers” setting defaulting to false. If you want IDLE to show line numbers, you must manually enable this settings every time you open the IDE. I think that it would be better to make show line numbers the default, and have it the other way around.
Line numbers are a crucial part of programming. They help us judge how long a code file is, count how long functions are, refer to specific parts of the code, and more. Line numbers are used everywhere - they are in the error messages of almost all programming languages (including python), they are used in the KLOC standard for judging how long a program is, and they are commonly used in github issues to identify which piece of code the person is talking about.
Since line numbers are so important, almost every IDE - and even most text editors - has them enabled by default. Visual Studio, Visual Studio Code, Jetbrains IDEs, Sublime Text, Notepad++, Netbeans, Atoms, Eclipse, Vim - you name it.
Since line numbers are so useful, and most designers and users of IDEs like having them, I think that it would make more sense to have line numbers tbe default. Much less people will have to opt out of showing line numbers than the amount of people that currently have to opt in to showing line numbers.
There are two common ways that line numbers are “shown”: as a column on the left-hand side with an explicit number beside each line; and as some status indicator near the bottom-right of the window indicating the line (and perhaps character) position of the cursor.
These are very different features that should not be conflated. Vim does the second by default and not the first, for example.
Karl, Thanks for pointing ti VIM as an example. IDLE also has line and column bottom right, on a status line, and optionally line numbers on the left.
@HorridModz Options => Configure IDLE => Shell/Ed => Editor Preferences has an entry to turn on line number for new files. It appears that you never found this, but only Options => Show/Hide Line Numbers. Please read the IDLE doc, available as Help => IDLE Doc, and look through the settings dialog.
Currently, there is one set of user configuration files, for everything in the Settings dialog, for all versions of Python and IDLE on a system. This mean that one only has to change the value for a particular setting just once, until you change your mind. Changing setting defaults is impossible unless we break this feature (which I love). The default new file line number setting was set after discussion among those participating at the time. Making a new feature optional is typical, to avoid upsetting people who do not want it.
Thanks for pointing this out, I was not able to find this out via a google search. Sorry for the oversight.
Yes, but this was a long time ago. Though I don’t have evidence, I bet the result of the poll would change if it was asked again in 2023. In my opinion, updating applications to modern standards is a good idea if it can be done without causing users too much hassle.
I’m sorry, I don’t see how this would “break this feature”. Can you please explain why?
I’m not so sure of that. Given that the setting is “sticky”, I personally would be quite happy for it to be off by default; for those who want it permanently on, it’s not a big deal to turn it on and leave it, and for those who need more room on their screens (perhaps because they don’t have much to start with), it’s better to not clutter it up.
For the record, the editor I use (SciTE) also has an option to display line numbers down the left hand side, and I usually leave it off. It’s a great feature when pair programming though; if I’m navigating and someone else is driving (which is the most common case for me - asymmetric pair programming as a teaching/mentoring method) it’s easier to say “line 91” than “over there”. Though that’s often somewhat diluted by the appalling quality of screenshare when Australian internet connectivity does its usual thing, but still.
The IDLE settings dialog is not very user-friendly or readable (what does “Shell/Ed” even mean? There seems to be enough space to fit “Editor” without abbreviating it?). Everything in the settings window is all over the place and misaligned. I shouldn’t need to consult a help file to figure out how to change this setting. IDLE has no settings search (like most other editors do), and its settings are much smaller, yet they are confusing to people.
The possibility to enable line numbers on a per-line basis isn’t something other editors have, so it might be confusing to users who are used to the other editors and expect line numbers to be a global setting saved in configuration (that you set once and forget about, or accept the reasonable default to have them enabled).
Also, the full name of the setting is “Show line numbers in new windows”, why is it not next to the “Initial Window Size” on the “Window” tab if they’re both about initial configuration of new windows?
Why is changing the default not possible? If this was fixed in Python 3.12, there are two things that could happen:
User likes the line numbers. If they go back to Python 3.11’s IDLE, there will still be no line numbers, and they will probably think that it’s a new IDLE feature. Or they might find it in IDLE 3.11 and enable it there too.
User does not like the line numbers. They will probably look for ways to disable it, they might even visit Help, the What’s New document, or a search engine, and figure out it’s in settings on that strangely named tab. They’ll disable the line numbers and they won’t have to see them ever again.
Only one of those ways is easy to spot, obvious to anyone, and makes it possible to scan line numbers, and it’s not the status bar one.
I’m new to this forum and I in no way have the right to tell others what to do, but this looks like you’re going off-topic and complaining about other aspects of IDLE. Considering posting your complaints in a new forum rather than putting them here.
I personally agree with you, but others in this thread seem to prefer the status bar one for their own reasons. So, I’m beginning to think it’s not as much as a 99 to 1 situation as you and I
had initially thought.
My point is that while there is a configuration option to enable line numbers by default, it is quite hard to find if you don’t know where to look, the configuration dialog is really badly designed, and the existence of the separate menu entry might cause people to stop looking altogether (just like it did in your original post). The fact that IDLE needs a UX designer is slightly orthogonal, but you could argue that if IDLE’s UX was better, this thread might not have happened at all.
IDLE would be considered by many a beginners’ IDE (the L is for Learning after all). Beginners might not be aware of the “current line number in status bar” convention, they might not even notice the status bar is there. Then they get an exception on line X. If X is small, they might count lines from the beginning of the file. Since the traceback usually includes the text of the line, they might try scanning code for that text, but it might appear in multiple places, or the code is not included in the traceback for some reason. Showing line numbers would improve beginners’ experience, even if established IDLE users are used to not having them.
Although I would personally recommends beginners go with VSCode or PyCharm instead for a much better experience, and not only with line numbering, but that’s off-topic. ↩︎
Yes, but if show line numbers were opt-in by default, the same problem would exist for people trying to go the opposite way. IMO, the bad UX is its own issue and should not be coupled with this issue - because no matter how easy or hard it is to enable show line numbers, my suggestion to make show line numbers the default still applies.
I can vouch this. IDLE was my first IDE for my first text-based programming language, and I taught myself rather than following any tutorials. Not only did the uneducated, naive noob that was me not notice the status bar, but I didn’t even know line numbers were a thing! Also, at the time, I was intimidated by the menu bar on top and I never ventured into it (with the exception of asking my mom for help figuring out how to create and run a new program), so I never discovered the Show Line Numbers option.
When I did run into exceptions, I would do exactly what you presumed - count lines or scan the code. Yes, this was a huge pain and terribly inefficient.
Like @Rosuav , I am not at all convinced that the vast majority of IDLE user would want this default changed. Even if I were, I would not, for the reason stated.
Changing values in idlelib/config-main.def does not work with IDLE’s current design because HOME/.idlerc/config-main.cfg only has the user value changes from config-main.def. A change (diff, patch) file cannot simultaneously record changes from different default settings. I tested this when I wanted to change another setting in config-main.def. (Fortunately, it is possible to add new keys, which is why the line-number setting could be added.)
If config-main.cfg were changed in 3.12 to record a user’s complete settings, then changing anything in 3.11 would change it back to a diff file.
I have considered adding something like “Starting with IDLE” to the Help menu to guide beginners through the main menu and suggest settings they might want to change. Of course, people would have to click Help to find it ;-).
When running pythonx.y.z, Help => IDLE Doc displays what is likely to be the best version of the IDLE doc for that version of python and IDLE. After the x.y.z release, updates to the online IDLE x.y docs replace the x.y.z version and while they may have some improvements that apply to IDLE x.y.z, they may also document IDLE changes that are not in the x.y.z release. This is partly why we went to the work of preserving and displaying a snapshot of the IDLE doc.
@HorridModz Something else you missed by not reading the doc:
Go to File/Line
Look on the current line. with the cursor, and the line above for a filename and line number. If found, open the file if not already open, and show the line. Use this to view source lines referenced in an exception traceback and lines found by Find in Files. Also available in the context menu of the Shell window and Output windows.
So, 2 mouse clicks on any of the middle four lines in this traceback
Traceback (most recent call last):
File "F:\dev\tem\tem.py", line 8, in <module>
points = [Point(0,7), Point(0,9)]
File "F:\dev\tem\tem.py", line 6, in __init__
self.z = 1/x
ZeroDivisionError: division by zero
would open tem.py in an editor window if not already and jump to line 8 or 6. In either case, discover that the 0 in Point(0,7) became the value of parameter ‘x’.
If the last opening line before the >>> prompt had been
Click “Help” above or enter “help” below for more information.
might you have been more likely to click on “Help”? How about
Click “Help” above to learn about some great but non-obvious IDLE features.
Enter “help” after “>>>” to learn more about python.
People simply don’t read Help/manuals these days. They won’t notice the extra line above the prompt either, and even if they do, they are unlikely to care about it. This is why good, obvious design and user-friendly defaults are important.
Also, what if someone is not proficient in English? The IDLE Doc menu entry would probably be useless to them, since it opens the English versions. There are some translations on docs.python.org, but this example Spanish one seems to have translated the menu items, which doesn’t match what is actually available in the IDE…
Again, that seems like a non-issue to me. Some users will have to go to the settings after upgrading, most (IMO) will be happy. And I doubt many people in the IDLE target audience switch between IDLE versions regularly.
@HorridModz Is correct that this post, off-topic and a bit rude here, should have started a new topic such as “Improve IDLE’s Settings dialog”. Quick responses:
I tried “Shell/Editor” but liked the short form a bit better. Either way, one needs to click and see the two frame labels to understand that the ‘true’ heading would be something like “Settings specific to either Shell window or Editor windows but not both”. “Shell only” and “Editors only” might be better frame labels. I will see if tk has options to make the label stand out more.
‘new windows’: I must have assumed that this phrase would be understood in context to mean ‘new editor windows’. I will add next editing.
The Help text for some tabs, but not this one, discusses individual settings. Perhaps better would be hover tips for each setting.
If you want to discuss improvements, open a new topic. Please omit generalized negative opinions.