I ran a git bisect and it seems like since commit 8d58bf4 back in 2016 this plugin breaks indentation after a byte string with an unclosed {, such as b'{', resulting in the following indentation:

if license.startswith(b'{'):
        print('json license')
        else:
        print('regular license')

I have no idea how a syntax highlighting plugin breaks this, but it does.

Reproduced on Debian 10 x64 and NVIM v0.5.0-799-g186ba3b68 with minimal init.vim:

call plug#begin('~/.config/nvim/plugged')
Plug 'vim-python/python-syntax'
call plug#end()

I don't understand VimL well, so what the different? Why don't just adapt this plugin to python.vim of vim8?

I've added some highlightings that I like, but not everyone might like them. So here's a screenshot that displays all the features I've added.

We can make syntax file more customizable on demand (as soon as anyone will ask for it I mean).

See hdima/python-syntax#32.

Vim does not colour strings properly, when the string is broken across multiple lines.

E.g. if this line:
return "Name: {0.name}, Lives: {0.lives}, Level: {0.level}, Score: {0.score}".format(player)
is broken like so:
return ("Name: {0.name}, Lives: {0.lives},
_______Level: {0.level}, Score: {0.score}".format(player))
the string highlighting stops at the end of the first line and then starts again in the next after the double quote.

(Sorry for the underscores, couldn't find a better way to represent the indentation I needed.)

The spellchecker is considering f'this in f'this is a f-string as a potential dictionary word and thereby highlighting it as wrong.

breakpoint was added to builtins.

Version: most recent commit, 6ce77d0 .

Problem: Setting let g:python_highlight_builtins=1 does not result in the expected syntax colouring for built-in functions, classes or types.

I selectively choose which options I want to have due to rendering limitations of gnome-vim, please see the options defined in my .vimrc (take note of the options that are commented):

let g:python_highlight_builtins = 1
let g:python_highlight_exceptions = 1
let g:python_highlight_func_calls = 1
let g:python_highlight_class_vars = 1
" let g:python_highlight_string_formatting = 1
" let g:python_highlight_string_format = 1
" let g:python_highlight_string_templates = 1
" let g:python_highlight_indent_errors = 1
" let g:python_highlight_space_errors = 1
" let g:python_highlight_doctests = 1
" let g:python_highlight_operators = 1

This is what I get - built-in types and functions take the same colour as normal functions, whereas built-in types are not coloured.

I had a look at the source and found the culprit. Currently working on a PR.

vim's rst syntax (maintained upstream at https://github.com/marshallward/vim-restructuredtext) is able to highlight embedded code fragments with their respective syntax files (basically starting at https://github.com/marshallward/vim-restructuredtext/blob/master/syntax/rst.vim#L153). It would be nice if python-syntax likewise provided an option to highlight docstrings using rst syntax (I believe this kind of behavior belongs to the wrapper syntax file (in this case python.vim) and not the wrappee (rst.vim), as the wrapper should be able to just say "use some other syntax file HERE" whereas the wrappee would have to guess what syntax element of the wrapper needs to be modified).

Was previously removed due to buggy implementation. See discussion in #1.

See also hdima/python-syntax#44.

In sublime text, the string literal prefixes (e.g, the "f" in f'a string') and function arguments (names and values) are separate highlight groups:

It would be nice if we could have this in vim, too. :)

pythonClassVaraible

expected:
pythonClassVariable

when 'bg=dark' on black terminals, dark blue doesnt really show up. The 'import' lines are all in this color. They should be lightblue or just bold-white.

What issues need to be fixed from the old repo over at hdima/python-syntax?

List them all here.

On line 376, PendingDepricationWarning should be PendingDeprecationWarning.

Currently, this plugins seems to not recognize the following expression, made valid by PEP 3107:

def apply(func:callable) -> int:
    return f(0)

The -> token is highlighted in red, probably because detected as an error.
This token does not appear in tests/test.py nor syntax/python.vim.
Builtin callable is not highlighted.

Github's highlighting of raw strings makes regexes more readable. For example:

var =  '^[a-zA-Z0-9]+([^\s\w\d])*\W{3,4}\[\]|(?:abc.+)\1$'  # not highlighted
var = r'^[a-zA-Z0-9]+([^\s\w\d])*\W{3,4}\[\]|(?:abc.+)\1$'  # highlighted

The above regex may not give the full picture, but we make some sense
of the highlighting. You have four colours for:

• dark-blue: regular text abc, and grouping chars (), (?: )
• light-blue: anchors characters ^, $, and character classes [a-zA-Z0-9], [\s\w\d], \W, .
• red: quantifiers *, +, ?, {3,4},, and special characters |, ^
• green: escapes including back-references \[\], \1

syn keyword pythonStatement     pass yield

syn match pythonStatement       '\s*\([.,]\)\@<!\<yield\>'

With current state it is matching whitespaces before yield. Do not recognizable if you have simple color theme, but if you have underline or bg(for pythonStatement) different from Normal - it will be noticeble.

And with new update we have
syn match pythonStetement '\s*[.,]\@<!\<yield\>'
Why do we even need this syn match beside syn keyword? Describe please.
If so i really think it should be something like this
syn match pythonStatement '\(\s*[.,]\)\@<!\<yield\>' But i'm still not sure why do we need this.

There seems to be a bug in the logic that detects previous syntax files here. On my Ubuntu machine with Vim 8, the default vim syntax file gets loaded first: /usr/share/vim/vim80/syntax/python.vim
This sets the '''b:current_syntax''' variable meaning the ptyhon-syntax script exits early due to the above lines. This results in several problems like missing highlights (#26 ) and commands missing (#61 ). Is this something specific to my setup or an actual bug?

If I set
autocmd BufNewFile,BufRead *.py setlocal iskeyword=A-Z,48-57,192-255,_,.,-,>

In string
con = sqlite3.connect(self.db)

or
aaa11113.ewfwefweffwe

Highliting(background red)
3. or 11113.

If I comment in ~/.vim/plugged/python-syntax/syntax/python.vim line
HiLink pythonNumberError Error problem fixing

Even though I have set python_highlight_builtin_funcs_kwarg to 0, builtins are still hightlighted in decorators, i.e. the type is highlighted in @click.arguments('foo', type = TAG).

The option for highlighting all builtins is not working although highlighting only functions and only objects do work.

Using Linux Mint 19 Tara and Vi Improved 8.0

Hi,

I set my tabstop to 4 explicitly in my ~/.vimrc and it works as expected in JS or C++ file BUT if I open python files the tabstop is 8 spaces

Why so?

P.S. See my .vimrc in my gists #

Currently, something like

(foo
 @ bar)

incorrectly highlights bar as a decorator, when it is in fact an operand of a matrix multiplication (note that this code conforms to the "new" PEP8 which suggests breaking before operators).

While a general solution may be tricky, it seems reasonable to only highlight as decorators when the @ is immediately followed by a letter (or underscore), without spaces in between. Spaces after the @ in a decorator are legal, but I have never seen cases where they are used...

Something like this, so the expressions look like code instead of the entire expression being highlighted the same.

f'a{b}c'

Hi,

thanks for the updated syntax.

I found some problems while using the standard vim syntax and this one. I had some very dense comment blocks in some files, and vim never worked quick in them.

I tracked down and syntax highlighting was to blame. However, I'm so used to it that i cannot code without it.

So I try to trackdown the HiLink command that was slowing everything and I found that changing the comment to underlined achieve a much faster navigation:

HiLink pythonComment Underlined

ps: using neovim

... because they are floats, not ints.

All's in the title.

I'm using VIM 8.1.1722, MacVim, on MacOSX Mohave 10.14.6

I installed this plugin using vim-plug.

I do not have the commands listed. Nothing comes up for 'Python2' or 'Python3'

First

Can we add some variable to enclose new(different from hdima/python-syntax)
self and cls in if statement? So people who do not need them can easily
disabable their highlight. Myself i actually use this highlight, but we need to
think about all users.

Second

Do you mind adding extra operators highlight group which you can find in
klen/python-mode syntax.
It looks like this

syn match pythonExtraOperator "\%([~!^&|/%+-]\|\%(class\s*\)\@<!<<\|<=>\|<=\|\%(<\|\<class\s\+\u\w*\s*\)\@<!<[^<]\@=\|===\|==\|=\~\|>>\|>=\|=\@<!>\|\.\.\.\|\.\.\|::\)"
syn match pythonExtraPseudoOperator "\%(-=\|/=\|\*\*=\|\*=\|&&=\|&=\|&&\|||=\||=\|||\|%=\|+=\|!\~\|!=\)"
syn match pythonExtraOperator "\%(=\)"
syn match pythonExtraOperator "\%(\*\|\*\*\)"

HiLink pythonExraOperator    Operator
HiLink pythonExtraPseudoOperator   Operator

You can check more at https://github.com/python-mode/python-mode/blob/develop/syntax/python.vim
I think with variable too, so people who need to highlght => == etc, can
turn them on.

Thank you.

See hdima/python-syntax#15.

In fr"{foo}" or rf"{foo}", foo is not highlighted as in f"{foo}".

https://github.com/achimnol/python-syntax
I have recently updated my own fork to support type annotations and fix some bugs in f-string highlighting. I didn't notice this new "official" fork here, so need to rebase my changes.
Please try a look on my new patches – and if you like those, I will make a new PR here.

In Python 3.6, a raw format string can be introduced with the prefix fr"... or rf"... (etc., see https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals). Such constructs are currently not recognized (https://github.com/vim-python/python-syntax/blob/master/syntax/python.vim#L196.

Thank you for the amazing work.

Is there a way to color else the same as try, catch and finally when in the context of a "try-catch" block?

When I break a long string in a return statement, the string is highlighted until the end of the line and not until the end of the string (' or " character). This can be easily fixed by modifying lines 154 and 155 in syntax/python.vim.

I find it difficult to see at a glance where f-string interpolation is happening.

Where:

print(f'hello {name}')

would add syntax matching for the { and } characters.

Also, even though general syntax highlighting for the interpolated name expression seems to be beyond vim's capabilities at the moment, it might be nice to match "everything inside the brackets" too.

delaying newline when this plugin enable.
syntax off has remove delaying of newline.

OS: macOS 10.12.5
vim 8.0.648

The following is syntime on my environment.
time of 10 times newline

  TOTAL      COUNT  MATCH   SLOWEST     AVERAGE   NAME               PATTERN                                                                                                              
  0.819285   11996  0       0.000639    0.000068  pythonError        [$?]\|\([-+@%&|^~]\)\1\{1,}\|\([=*/<>]\)\2\{2,}\|\([+@/%&|^~<>]\)\3\@![-+*@/%&|^~<>]\|\*\*[*@/%&|^<>]\|=[*@/%&|^<>]\|-[+*@/%&|^~<]\|[<
  0.817784   29630  23438   0.000123    0.000028  pythonNumber       \<\d\>
  0.753679   12006  0       0.000501    0.000063  pythonBuiltinObj   \v\.@
  0.691795   12006  0       0.000202    0.000058  pythonRawFString   \%([fF][rR]\|[rR][fF]\)'
  0.686025   12006  0       0.000178    0.000057  pythonRawBytes     \%([bB][rR]\|[rR][bB]\)'
  0.684235   12006  0       0.000275    0.000057  pythonRawFString   \%([fF][rR]\|[rR][fF]\)"
  0.682016   12006  0       0.000210    0.000057  pythonRawFString   \%([fF][rR]\|[rR][fF]\)"""
  0.680987   12006  0       0.000269    0.000057  pythonRawBytes     \%([bB][rR]\|[rR][bB]\)"
  0.678611   12006  0       0.000222    0.000057  pythonRawBytes     \%([bB][rR]\|[rR][bB]\)"""
  0.676308   12006  0       0.000249    0.000056  pythonRawBytes     \%([bB][rR]\|[rR][bB]\)'''
  0.671002   12006  0       0.000160    0.000056  pythonRawFString   \%([fF][rR]\|[rR][fF]\)'''
  0.515513   12006  0       0.000167    0.000043  pythonStatement    \v\.@
  0.364002   11996  0       0.000136    0.000030  pythonFloat        \<\d\%([_0-9]*\d\)\=[eE][+-]\=\d\%([_0-9]*\d\)\=[jJ]\=\>
  0.360106   11996  0       0.000139    0.000030  pythonNumber       \<[1-9][_0-9]*\d\>
  0.356433   11996  0       0.000101    0.000030  pythonNumberError  \<\d[_0-9]*\D\>
  0.355913   11996  0       0.000136    0.000030  pythonFloat        \<\d\%([_0-9]*\d\)\=\.\d\%([_0-9]*\d\)\=\%([eE][+-]\=\d\%([_0-9]*\d\)\=\)\=[jJ]\=
  0.354540   11996  0       0.000119    0.000030  pythonNumber       \<\d[jJ]\>
  0.353304   11996  0       0.000085    0.000029  pythonError        \<\d\+[^0-9[:space:]]\+\>
  0.348086   11996  0       0.000124    0.000029  pythonNumber       \<[1-9][_0-9]*\d[jJ]\>
  0.341373   11996  0       0.000095    0.000028  pythonNumberError  \<\d[_0-9]*_\>
  0.337073   12006  0       0.000068    0.000028  pythonBytes        [bB]"
  0.335773   12006  0       0.000221    0.000028  pythonRawString    [rR]'
  0.334479   12006  0       0.000130    0.000028  pythonFString      [fF]'''
  0.334453   12006  0       0.000108    0.000028  pythonBytes        [bB]"""
  0.333616   12006  0       0.000624    0.000028  pythonRawString    [rR]'''
  0.333267   12006  0       0.000084    0.000028  pythonFString      [fF]"
  0.331618   12006  0       0.000076    0.000028  pythonRawString    [rR]"
  0.328148   12006  0       0.000115    0.000027  pythonFString      [fF]"""
  0.327392   12006  0       0.000085    0.000027  pythonBytes        [bB]'
  0.327190   12006  0       0.000071    0.000027  pythonRawString    [rR]"""
  0.326874   12006  0       0.000183    0.000027  pythonFString      [fF]'
  0.316021   12006  0       0.000101    0.000026  pythonBytes        [bB]'''
  0.108732   12006  0       0.000046    0.000009  pythonImport       ^\s*\zsfrom\>
  0.092719   11996  0       0.000041    0.000008  pythonDecorator    ^\s*\zs@
  0.061592   12006  0       0.000028    0.000005  pythonStatement    \
  0.039693   12006  0       0.000018    0.000003  pythonStatement    \
  0.038589   11996  0       0.000034    0.000003  pythonFloat        \.\d\%([_0-9]*\d\)\=\%([eE][+-]\=\d\%([_0-9]*\d\)\=\)\=[jJ]\=\>
  0.033351   12006  0       0.000017    0.000003  pythonCoding       \%^.*\%(\n.*\)\?#.*coding[:=]\s*[0-9A-Za-z-_.]\+.*$
  0.016517   12256  520     0.000649    0.000001  pythonComment      #.*$
  0.015556   12006  0       0.000016    0.000001  pythonRaiseFromStatement \
  0.014932   12006  0       0.000016    0.000001  pythonStatement    \
  0.008733   1146   1146    0.000023    0.000008  pythonFunction     \%([^[:cntrl:][:space:][:punct:][:digit:]]\|_\)\%([^[:cntrl:][:punct:][:space:]]\|_\)*
  0.008377   37476  30337   0.000002    0.000000  pythonDot          \.
  0.004791   11996  0       0.000020    0.000000  pythonNumberError  \<0[bBxXoO][_0-9a-fA-F]*_\>
  0.004767   12006  0       0.000009    0.000000  pythonString       """
  0.004714   11996  0       0.000009    0.000000  pythonBinNumber    \<0[bB][_01]*[01]\>
  0.004631   12006  0       0.000010    0.000000  pythonRun          \%^#!.*$
  0.004540   11996  0       0.000010    0.000000  pythonBinError     \<0[bB][01]*[2-9]\d*\>
  0.004321   12006  0       0.000019    0.000000  pythonBytesEscape  \\$
  0.004185   11996  0       0.000003    0.000000  pythonHexNumber    \<0[xX][_0-9a-fA-F]*\x\>
  0.004170   11996  0       0.000001    0.000000  pythonNumberError  \<0_x\S*\>
  0.004165   11996  0       0.000009    0.000000  pythonOctError     \<0[oO]\=\o*\D\+\d*\>
  0.004164   12006  0       0.000009    0.000000  pythonString       "
  0.004153   12006  0       0.000009    0.000000  pythonString       '''
  0.004139   11996  0       0.000010    0.000000  pythonHexError     \<0[xX]\x*[g-zG-Z]\x*\>
  0.004126   11996  0       0.000009    0.000000  pythonOctNumber    \<0[oO][_0-7]*\o\>
  0.004120   12006  0       0.000010    0.000000  pythonString       '
  0.004064   11996  0       0.000004    0.000000  pythonBinError     \<0[bB][01]*\D\+\d*\>
  0.004063   11996  0       0.000009    0.000000  pythonNumberError  \<0[_0-9]\+\>
  0.003967   11996  0       0.000011    0.000000  pythonOctError     \<0[oO]\=\o*[8-9]\d*\>

15.668772   752624

I'm using VIM 8.1.1722, MacVim, on MacOSX Mohave 10.14.6.
I installed this plugin with vim-plug, most recent version at the time of writing.

I have a pytest decorator that looks like this:

@pytest.mark.parametrize("sent, count", [("()",0),
                          ("«»",0),
                          ('text test "testing test.', 1)])

and when highlighted in vim using python-syntax, it looks like this:

Everything that comes after this is also badly colored, basically with inverted string highlighting: everything that is a string is highlighted like code and vice versa.

I dunno who made this change, but now you can't reach pythonBuiltinFunc highlighting group. Because this
syn match pythonIdentifier '\v[a-zA-Z_][a-zA-Z0-9_]*' nextgroup=FunctionParameters
overwrites any of this

  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(__import__|abs|all|any)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(bin|chr|classmethod|cmp|compile|complex)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(delattr|dir|divmod|enumerate|eval)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(filter|format|getattr)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(globals|hasattr|hash|hex|id)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(input|isinstance)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(issubclass|iter|len|locals|map|max)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(min|next|oct|open|ord)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(pow|property|range)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(repr|reversed|round|setattr)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(slice|sorted|staticmethod|sum|super)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(type|vars|zip)>\ze\(' nextgroup=FunctionParameters

Why do you even change syn keyword(that has precedence over match) to syn match for builtins?

From the screenshot, notice how from, as, and is get highlighted when they're used as arguments or variable names, this shouldn't be the case?

Is this a legit bug or am I missing a configuration.

Looks weird in for-in loops:

See: http://vi.stackexchange.com/a/10641

Thanks!

As python 3.6 gave us f-strings it's I've been using them more over the ol' .format() syntax.

Sadly, the syntax is highlighting strings that have curly braces but have neither f-string prefix or .format suffix.

The third statement ("{hello}") shouldn't show the curly brace because that is not doing anything fancy with the string. It's just a string.

This might lead me as a developer to miss putting the f-prefix before a string, as the curly braces are giving an indication that they are treated as some sort of templates.

Any thoughts on this?

In (e.g.) 2**-3, *- is spuriously highlighted as a syntax error.

Hello, this is probably pretty dumb, but I can't seem to find an answer for this

I'm using Vim v8.0 on a WSL and I can't get any highlights from vim-python (unused imports, unused arguments, misspelled names, etc.)

Here is the vimrc and i'm using vim-plug

call plug#begin('~/.vim/plugged')           
Plug 'altercation/vim-colors-solarized'                         
Plug 'jnurmine/Zenburn'             
Plug 'vim-python/python-syntax'            
call plug#end()                          

if has('gui_running')               
	set background=dark           
	colorscheme solarized                                                                                                                                                                                                    
else
	colors zenburn
endif

set number

filetype plugin indent on
syntax on

I executed :PlugInstall as well.

And a look at my ~/.vim/plugged

>> ls
python-syntax Zenburn vim-colors-solarized

What could I be doing wrong/missing?
Thanks

First off, thanks for maintaining this!

I'm wondering if there are plans to upstream these improvements into the upstream Vim syntax highlighting, so that this is directly bundled with Vim.

It seems there's been a lot of improvements on this fork, so I'm curious why not merge them back.

I've looked around a bit and haven't seen mentions of this, so I'm not sure if this has been discussed or not.

It mostly feels odd that Vim ships a "less enhanced" version, and that there's a fork with further improvements -- maybe efforts could be unified?

Installed with vim-plug, set let g:python_highlight_all=1, but no highlighting for exceptions, booleans and None.

Currently "%h" (and l, L) are recognized as printf style formats (https://github.com/vim-python/python-syntax/blob/master/syntax/python.vim#L238). While they are technically legal, they are also useless in Python and likely very rarely used (https://docs.python.org/3.6/library/stdtypes.html#printf-style-string-formatting "A length modifier (h, l, or L) may be present, but is ignored as it is not necessary for Python – so e.g. %ld is identical to %d.").

I would thus suggest turning them off (to decrease the number of "false" highlightings where the % is, well, just a percent sign), or at least make that configurable.