pgjones / flake8-sql

Flake8 plugin that checks SQL code against opinionated style rules

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Python 3.8 changes behaviour and makes noqa for multiline strings impossible

RobertKirk opened this issue · comments

When upgrading to python 3.8, flake8-sql suddenly started complaining about queries which before were passing fine. Some examples:

from sqlalchemy.sql import text

# passes the flake8 linter in python 3.8
sql = text(
    """
       UPDATE entry
          SET helpful = :helpful
        WHERE id = :entry_id
    """
)


# passes the flake8 linter in python 3.7, but fails in 3.8 
# due to complaining about alignment of root_keywords
# Q447 root_keywords UPDATE and SET are not right aligned
# Q447 root_keywords UPDATE and WHERE are not right aligned
sql = text(
    """UPDATE entry
          SET helpful = :helpful
        WHERE id = :entry_id"""
)


# fails the linter in python 3.8, as DATE_TRUNC is not valid, but noqa isn't picked up.
# It looks at the line of the opening """, not the closing one as before.
sql = text(
    """
       UPDATE entry
          SET processed = DATE_TRUNC(:processed)
        WHERE id = :entry_id
    """  # noqa
)


# passes the flake8 linter in python 3.7, due to noqa being picked up
sql = text(
    """UPDATE entry
          SET processed = DATE_TRUNC(:processed)
        WHERE id = :entry_id"""  # noqa
)

The second issue this brought up, as mentioned in the 3rd example, is that when using multiline strings like the ones above, the flake8-sql error is now registered to the first line of the query (the opening """). This means there's nowhere to place the # noqa comment to ignore the errors. Before the error was registered to the line of the close """, so the comment could go after there (as in the 4th example). I imagine this is something to do with python changing how the AST looks like for multiline strings, but it's preventing us from upgrading to python 3.8 as there's some errors we have to ignore.

I realise 3.8 only just released, so it might be worth waiting until the 3.8.1 release for stability before tackling the issue, but I thought it'd be worth raising the issue now.