bug#43298: 27.1; Do font locking for Python 3, not 2

bug#43298: 27.1; Do font locking for Python 3, not 2

[Per Starbäck]

In GNU Emacs 27.1:

	$ emacs -Q -f /tmp/new.py
        for RET print RET len RET

"print" gets the same colour as "for", that is as a keyword.
I think it should get the same as "len", that is as a builtin
function.

Python.el has a section

          ;; Python 2:
          "print" "exec"

because in Python 2 these two were keywords. But in Python 3 they are built-in
functions.

I think it's overkill to try to determine if the buffer contains Python 2 or 3
and highlight them differently. Using the same fontlocking is good enough,
since it's not a big problem to get these in the wrong colour.
But now when Python 2 is officially discontinued I think it's time to
let it follow Python 3 and get the small inconvenience when editing old
code and not when editing current code.

bug#43298: 27.1; Do font locking for Python 3, not 2

[Kévin Le Gouguec]

This is one of my long-standing pet peeves, thanks for filing an issue
about it.  FWIW here is how I thought I'd go about fixing this Whenever
I'd Find The Time™ (… needless to say, if anyone wants to beat me to it,
there'll be no hard feelings):

1. Add fontification tests for the current fontification.
   (Because I expected the overall patch to be quite big, and I figured
   it'd be easier to get it merged if it came with a bunch of
   non-regression tests.)

2. Create 3 sets of font-lock settings in python.el: -2, -3, and
   -undecided (= whatever the current settings do).

3. Add a variable to control which settings to use (settable through
   Customize or through file/directory-local variables).

4. Add heuristics to pick the "right" style by default (e.g. look for a
   shebang).


On the one hand, I agree that Emacs should be py3k-compliant by now
out-of-the-box.  On the other hand, I'd bet there are a lot of poor
souls out there who will be stuck maintaining Python 2 code for a few
more years.  Messing with font-lock without giving them an escape hatch
sounds like some form of double-jeopardy…

bug#43298: 27.1; Do font locking for Python 3, not 2

[Stefan Kangas]

close 43298 29.1
thanks

Per Starbäck <starback@cl.lingfil.uu.se> writes:

> In GNU Emacs 27.1:
>
> 	$ emacs -Q -f /tmp/new.py
>         for RET print RET len RET
>
> "print" gets the same colour as "for", that is as a keyword.
> I think it should get the same as "len", that is as a builtin
> function.
>
> Python.el has a section
>
>           ;; Python 2:
>           "print" "exec"
>
> because in Python 2 these two were keywords. But in Python 3 they are built-in
> functions.

Thanks for the bug report!  Your reasoning makes sense to me, so I have
now fixed this on master (commit 9f9c9f934a).  This change will be in
Emacs 29.

Feel free to verify that this fix works for you, but for now I'm closing this
bug report.  If you see anything that is wrong, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

> I think it's overkill to try to determine if the buffer contains Python 2 or 3
> and highlight them differently. Using the same fontlocking is good enough,
> since it's not a big problem to get these in the wrong colour.
> But now when Python 2 is officially discontinued I think it's time to
> let it follow Python 3 and get the small inconvenience when editing old
> code and not when editing current code.

Agreed.