Another new syntax in Python 3.6 is allowance of underscores in the middle of numeric literals to improve readability of long numbers.
https://docs.python.org/3.6/whatsnew/3.6.html#whatsnew36-pep515

Let's add support for this as well. :)

how to mark starting and ending strings with """ or ''' as comment

currently as a workaround I added the following to the .vim/after/syntax/python.vim file

syn region Comment start=/"""/ end=/"""/
syn region Comment start=/'''/ end=/'''/

print has changed from a statement to a built-in function between Python 2 and 3. I would expect the syntax highlighting to reflect this change.

congma/vim-syntax-python@21886ee prevents "builtins" from being highlighted when they appear as attributes of another object. It would be nice to port this fix to this repo too.

Note that the fix is incomplete as it assumes there are no spaces around the dot, whereas python actually allows arbitrary whitespace there (subject to normal line continuation rules).

How to use the folding file in folding-ideas folder?

"{{" (and likewise with closing braces) are highlighted as if they were introducing formatting elements though they are actually escapes.

I don't believe this syntax is supported in your python.vim, is it?

{x:y for x,y in [(1,2), (3,4)]}

self is the standard keyword for self-reference in Python OO. I suggest that we link it to special.

I tried to find prior discussion about this since I felt that this kinda had to be discussed before, but I found nothing. Apologies if that was the case!

Python 3.6 has reached its last beta where its features are frozen now.
It introduces a new syntactic element: f-string literals.
https://docs.python.org/3.6/whatsnew/3.6.html#whatsnew36-pep498

In f-string literals, the content inside braces are treated as real Python expressions with optional format string after a colon character like in format() protocol. The expression expansion may be done inside the format string as well though. (See the examples in the above link.)

Let's add support for this.

Highlighting for async and await definitions. I added the python.vim file to the syntax folder on .vim. Still can't get it to highlight this as Language keywords

You should re-think how you select between the two Python syntax versions. The current method allows setting g:python_version_2=0 globally for python3 and lets buffers set b:python_version_2=1 for python2. But it doesn't allow setting g:python_version_2=1 to ensure python2 is the default and setting b:python_version_2=0 to get python3 for a single buffer.

Python 3.5 introduced @ as the matrix multiplication operator (https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-465). Unfortunately, this syntax file is still highlighting the term after @ as if it was a decorator.

Like it or not, the pyrex syntax file shipped with vim7.4 (extension .pyx) forcefully loads the python syntax file and clears the pythonInclude group, leading to an error with this python syntax file as it does not define pythonInclude anymore.
I would thus suggest providing an empty pythonInclude group to avoid this issue.

Is there a preferred way to use proper folding with python-syntax ?

By "proper folding" I mean not a trivial folding solely indent based but a more decent one based on def, class and # {{{ }}} markers declarations.

I tried to use Python-Syntax-Folding and braceless.vim but none seems to be compatible with python-syntax.

The indent mode of Python-Syntax-Folding suits my needs but lacks python 3 syntax.

..and the fix is:

diff --git a/syntax/python.vim b/syntax/python.vim
index e461241..4ad66b3 100644
--- a/syntax/python.vim
+++ b/syntax/python.vim
@@ -176,7 +176,7 @@ else
   syn keyword pythonBoolean     True False
   syn match   pythonFunction    "\%([^[:cntrl:][:space:][:punct:][:digit:]]\|_\)\%([^[:cntrl:][:punct:][:space:]]\|_\)*" display contained
   syn keyword pythonStatement   await
-  syn match   pythonStatement   "\<async\s\+def\>" display
+  syn match   pythonStatement   "\<async\s\+def\>" nextgroup=pythonFunction skipwhite
   syn match   pythonStatement   "\<async\s\+with\>" display
   syn match   pythonStatement   "\<async\s\+for\>" display
   syn match   pythonStatement   "\<async\s\+with\>" display```

To me, the Special highlighting should be for things that stand out, so it shouldn't be used for large blocks like the shebang and coding header.

It would be nice if this could be an option that determines whether pythonRun and pythonCoding are linked to Special or Comment.

Such as:
4 error| W0611 "sys" imported but unused [pyflakes
18 col 6 error| E225 missing whitespace around operator [pep8
34 col 6 error| E231 missing whitespace after "," [pep8
114 col 5 error| E303 too many blank lines (3) [pep8
141 col 1 warning| W391 blank line at end of file [pep8

Hello.

I am really enjoying your work to the point I would like to add a Gentoo ebuild for it into my overlay so other people can grab it and update with ease. Gentoo ebuild writing policy requires each package to have a license. I was unable to find any mention of this project's license. Can you please tell me what it is?

Thanks.

Hello.
Please, add this futures.
https://www.python.org/dev/peps/pep-0492/

Hi,

I install python-syntax by vundle:

Bundle 'hdima/python-syntax'

Add add the following setting in _vimrc

let python_highlight_all = 1

However, keyword cannot be shown.
Color file which I used is: https://github.com/Marslo/marslo.vim/blob/master/colors/marslo256.vim

Would be nice if you could add highlight error for unmatched and unbalanced parenthesis/square brackets/curly braces/etc. For example, marking everything after (to the end of the file) an unclosed parenthesis in a function definition, to be highlighted with red background, or everything before (to the beginning of the file) an additional closing bracket without a corresponding starting bracket, or everything inside an opening parenthesis with closing bracket (unbalanced grouping stack).
That way, could be easier to identify balancing errors in big enclosed declarations, like that from big nested dicts declarations.
Thanks for the great work.

@hdima

I have an issue I made at python-mode/python-mode#353 about syntax highlighting with vim.

Here is the post:

Taking a look at pocoo code / many python projects, here are some common variable names:

fix_tuple_repr - highlighting tuple and repr
implements_bool - highlight bool
range_type highlights range and type
file_something highlights file

Is this expected behavior? Is this considered a feature? An option or a bug to fix?

Hi,
I design this Paper Color theme, and it supports your syntax plugin. Do you plan to make your plugin to recognize non-alphanumeric tokens like ( ) [ ] , . + - * / = < > ?

All's in the title.

Hi there,

I find that bugs like

foo = 42,

are fairly common that it would be valuable to highlight the , in that scenario. While this syntax is technically correct in creating a tuple, I find that it's unintentional 80% of the time and drawing more attention to it would be valuable.

Closest solution I've hacked together is:

syn match PythonTrailingCommaWarning    "[=].*\(,\)\s*\(#.*\)*$" display

I'd love for something like this to be included in this syntax file, but there are some improvements that could be done if anyone is more familiar with how Vim syntax files work:

• Only highlight the ,, not the entire substring starting from = ...
• Include the scenario where it's return ...,
• Exclude the scenario where it's foo = "bar, #"

Though I find that even without these improvements, this addition is already useful in catching these annoying bugs. :)

I've searched and found issues about that
#21
#10

And I find you arguments very weak.

So your first argument:

I actually tried it and I don't really like how it looks. It adds too many colors to the code to the point that it's getting harder to follow.

Really? You think that fist example is less readable then the second? I (and obviously a lot of people) don't. I think it's more readable.

If you can easily filter class fields from other variables and stuff it is beneficial. You can't doubt that, don't you? I strongly think if you somehow did it so that when self is highlighted it is harder to you to follow code, you just did something wrong with colors, that's it.

You second argument.

self is actually just a conventional name for the first argument of a method. And if somebody uses for example just s instead it won't be highlighted and just will be confusing.

Well then s is should be highlighted also, or any other name that is the pointer to class instance. And pycharm is actually doing just that. But that's probably involve actually parsing file or something and is harder (or impossible) to do with regexp. If that is so, than you should state so.

You last argument

As it just an argument of a method it also can raise a question "why the other arguments not highlighted?" and also can add to the confusion.

I will answer this 'confusing' question. Well, I've already answered it actually, so I'll just repeat myself. Because it's beneficial to filter class fields from other stuff in methods.

So to state my point again.
It is obviously beneficial to filter class field from other stuff. If it's impossible, say so. If it's hard and I you doubt my arguments, so you won't do it yourself, than if you could guide somehow to the solution many will thank you for that (including me). If it's easy, but you won't do it, then again, it would be nice if you could provide help on how to do that.

A couple of "builtin globals" (actually module attributes) are missing highlighting: __loader__, __spec__, __path__ and __cached__ (see https://docs.python.org/3/reference/import.html#import-related-module-attributes).

the env is nvim and python3.5

Seems like this project is completely dead.

We can base the new fork on work done by purpleP and lilydjwg.

New repo at vim-python/python-syntax.

I noticed that the "else:" statement (with colon) is not correctly highlighted. Adding "else:" to line 156: syn keyword pythonConditional remedied the issue.

Hi,

I've using Rainbow Parentheses.vim to make code pretty.
However, rainbow parentheses cannot work after using "python-syntax".

I know to disable a operation by using:

:let OPTION_NAME = 0

But I don't know which operation including parentheses?

Thanks.

As you can see from screenshots pycharm nows that len is bultin function and hightlights it, but if I define variable named len for some evil reason (and I sometimes do it with dict) it knows that it's the variable and not the function call, so it doesn't highlight it, unlike your highlighter.

Hi,
Thanks for maintaining this. Really appreciate your work. Here's the issue I'm reporting:

Although I like having the @Spell option enabled for pythonComment, the same option for strings is a bit distracting because, typically my code doesn't usually have too many 'user consumable strings', however, it does have a lot of strings as keys to dicts etc:

  d= {'top_nav' : ..., 'err_msg' : ...} 

...which then get highlighted as spell errors. Is it possible to make this a configurable option, like python_spell_check_comments and python_spell_check_strings.

This isn't a big pain, just a suggestion. So feel free to close this issue with a WONTFIX . Thanks again for your work.

cheers,
steve

When I enabled this package, it messed up the autotabbing behaviour of vim making it effectively unusable. Seems like #62 ("the project is dead: time to fork") might be right, as that's some pretty basic behaviour that is broken.

Please add new syntax hightlight (async, await) in Python3.5

https://www.python.org/dev/peps/pep-0492/

This plugin's syntax file treats None as a pythonBuiltinObj for Python 2, but as a pythonStatement for Python 3. This causes different highlighting for None in Python 2 versus Python 3, since pythonBuiltinObj maps to the Structure group, but pythonStatement maps to the Statement group.

1. Why did this plugin's maintainers decide the highlighting group for None should be different between Python 2 and Python 3? I'm not aware of anything different in the behavior of None from Python 2 to Python 3.
2. Doesn't None — a builtin constant — most logically map to the Constant group, rather than Structure or (especially) Statement? (The same goes for other builtin constants like True, False, etc.)

Hello,

the yield from construct introduced in PEP 380 is not correctly highlighted. The from portion is highlighted as the standalone from statement, as opposed to the entire statement which should be highlighted as a keyword (that is, from preceeded by yield should be highlighted as as keyword).

Any chance of adding support for function annotations? https://www.python.org/dev/peps/pep-3107/

print("Today is {:%A %B %d}".format(datetime.date.today())) is highlighted incorrectly. mrrech/python-syntax@8b43134 provides a "partial" fix but it's not really enough.

Like so. This is also beneficial