(python) exec and print should be highlighted as built-ins

[Lestoroer]

If I'm using just print then this is highlight.
But if I'm using print() then this isn't highlight.
<code class="python highlight"></code>

[isagalaev]

It's by design. print() is a Python 3 thing where print is not a keyword.

[Lestoroer]

Highlight js uses python 2?

[isagalaev]

It tries to highlight Python code of both versions, but makes a guess on how to highlight print depending on how it's used.

[Lestoroer]

Is it possible to make highligthing print()?
I guess this is used very much on sites and users would like to see highligthing this.

[isagalaev]

That's unlikely. It's not a keyword in Python anymore, and I don't see the point in highlighting it as one. Also, I'd need some data on how many users actually want it highlighted. It's the first time anyone raises this point.

[Lestoroer]

I see, Thank you for your work!
But please to think about it because sublime, visio code, eclipse, Python IDE highlighting this.

[typemytype]

I really would like you to reconsider print("hello world") in a python 3 world. Its indeed not a keyword anymore, but its part of the built ins. I see that build ins are not at all supported see https://github.com/isagalaev/highlight.js/blob/master/src/languages/python.js#L12-L13

see a list of built ins: https://docs.python.org/3/library/functions.html

thanks

[samuelcolvin]

Is there any chance this could be reconsidered?

As an example, github's highlighting does highlight print:

a = 5
print('foobar', a)

[joshgoebel]

Read everything above and make a case for why it should be reconsidered. It won't be reconsidered just because you asked nicely - we need a good reason. :)

"GitHub does it this way" isn't a case. :)

[typemytype]

see t-h-e p-y-t-h-o-n b-u-i-l-d-i-n-s l-i-s-t, don't know how much clearer it should be...

dont reconsider if you want to be stubborn and being stuck in whatever reason this is holding you back, asking nicely should always be a +1 above demanding it

[samuelcolvin]

"GitHub does it this way" isn't a case. :)

This is a self-evidently incorrect statement. Github doing it this way is a case to change highlight.js's behaviour, it may (on its own, in your opinion) not be a conclusive case, but that doesn't mean it's not a case.

Similarly pygments (the preeminent code highlighter in python) highlights print() as does python's own docs. These are also cases that highlight.js should follow suit.

But I agree with @typemytype that the conclusive argument is that print() is a builtin, so it's an error that it's not wrapped in an element with the hljs-built_in class by hightlight.js.

Remember, we're not suggesting that hightlight.js forces people to highlight print(), just that they make it possible.

---

Overall, as someone who reviews (and often refuses) feature requests & bugs everyday, the case that this should not be changed is pretty thin.

[joshgoebel]

This is a self-evidently incorrect statement.

Indeed. I will be clearer next time. You understood my meaning though. :)

Overall, as someone who reviews (and often refuses) feature requests & bugs everyday, the case that this should not be changed is pretty thin.

I tend to assume past behavior has reasons (and they made sense to me last time I looked at this) - and our very own library author made this change himself... so... that makes the burden perhaps a bit higher. :-) That plus a bit of "say no by default" mixed in.

conclusive argument is that print() is a builtin, so it's an error that it's not wrapped in an element with the hljs-built_in class by hightlight.js.

This seems quite compelling. Reviewing. At the time these changes were made (excluding exec and print) we did not track built_ins separately (at least not in this grammar)... they were keywords... so Ivan was taking the correct step of not highlighting them as keywords any longer.

But since we do highlight built-ins it does seems these should again be highlighting - now as built-ins.

[samuelcolvin]

Thanks for reconsidering, I agree entirely with "say no by default", but I think making an exception to that rule here is a good decision.

[samuelcolvin]

PR created.

[isagalaev]

I'm still subscribed to this ticket for some reason, so I've read the recent back and forth… I should say @joshgoebel is a saint, were it for me I'd closed and sealed it simply because of sheer amount of entitlement and rudeness in this "discussion". Especially considering that all it should've taken would be pointing out that print is already in built-ins and just doesn't work for some reason. Then it would be a matter of fixing a bug, instead of grand-standing your opinion what someone else's project "should follow".