Inconsistent variable highlighting?
See original GitHub issueOS X 10.11.2, Sublime Text 3113, Gravity theme, latest MagicPython.
Trying out MagicPython from PythonImproved. In the first Python file I opened, I see:

X_train
and X_test
are highlighted purple, but y_train
and y_test
are white. Capitalizing the Y vars turns them purple.
I’m assuming that any word starting with a capital is treated as a “constant” and colored accordingly. Is this intentional? Wouldn’t checking for ALL_CAPS be better?
Issue Analytics
- State:
- Created 7 years ago
- Comments:11 (7 by maintainers)
Top Results From Across the Web
Syntax highlighting issue - variable highlighting is inconsistent ...
Seems like any variables to the right of a binary operator don't highlight. All reactions.
Read more >Inconsistent highlighting in oXygen when || operator is used ...
... the highlighting is inconsistent, e.g. in expression: <xsl:value-of select="$v1 || $v2"/> only $v1 is highlighted as variable, $v2 is not.
Read more >Highlighting Inconsistent Record Entries in EXCEL - Lex Jansen
This paper describes two methods for highlighting inconsistent record entries in an EXCEL spreadsheet. The first.
Read more >Excel Tips: A Trick for Finding Inconsistent Data - GCFGlobal
Finding inconsistent data in a large spreadsheet can be time consuming. This Excel trick can make it much easier.
Read more >Inconsistent behaviour when attempting to highlight C# TextBox
I had the same problem today. I tried changing TopLevel as others have suggested. This didn't work. Somewhere along my search I saw...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
After months of deliberations (believe it or not, we actually talked about this many times) we’ve come to the conclusion that single-upper-case-letter constants are probably more of an exception that the typical use case in generic code.
The module
math
defines its constants as lower-case anyways (so it’se
and notE
). In general, in sciences and math single-letter constants are frequently lower-case, so we can assume that for readability that will be the style used in code for established constants (c
,e
,g
,h
, etc.), likewise there are some established single-letter constants that are traditionally upper-case (G
,R
,H_0
). These are very specific domains, though. It’s likely that within them there is no strong need to add emphasis to these constants in code as people using them are already conditioned to pay attention to these special symbols.In a generic program, however, single-letter variables are more likely indicating a temporary intermediate computation result or similarly a result that is not meriting extra emphasis. It is considered good style to give important global concepts (classes, functions or constants) a meaningful human-readable name. If the name is long and readable, but only contains a single upper-case letter, it’s more reasonable to conclude that this doesn’t merit extra emphasis and is probably not a constant (e.g.
X_train
or even single-letter classX
).Hey! recently discovered this cool project. Awesome work!
Regarding this issue, I actually use this ‘bug’ to highlight some variables. It helps with a quick high level view of the flow.
Coincidently, I am apparently viewing the same script as @pikeas and really like how I can keep track of
X_train
andX_test
.Just adding my two cents.