Scope-level comments

[dsuch]

Hello,

could you please add to your roadmap the implementation of Python scope-level pragma comments?

For instance:

def func():
    # pyright: disable=reportUnknownMemberType
    return self.socket.accept()

Generally, this is useful when dealing with third-party libraries when one simply knows what to ignore.

# pyright: strict

def func():
    def inner():
        # pyright: typeCheckingMode=off
        result = call_an_external_library()

        # Do something with the result
        ...

    # Meanwhile in func, we have been in the strict mode all the time
    ...

There are various ways to work around such situations but simply having a way to explicitly drive the type checker with a pragma comment would be very useful.

Thank you.

[erictraut]

We currently have no plans to add scope-level comments, so there's no roadmap to speak of.

The Python typing standard defines line-level diagnostic suppression via a # type: ignore comment. The same can also be used to suppress all type errors in a file if the comment is placed at the top of the file.

Pyright adds pyright-specific control at the file level using # pyright: xxx style comments.

We might consider adding some form of block-level control if enough users indicate that it's important to them, but it would require some internal discussion about how to get the details right. Also, unless it goes through a PEP standardization process, such a solution would be pyright-specific and wouldn't work with other Python type checkers.

Here's one somewhat-related issue in the pylance issue tracker: #282.

In my experience, there's usually a better way to deal with type errors than suppressing them. A combination of type annotations, casts, and asserts takes care of the vast majority of type errors, and these approaches result in more robust code than simple suppression. If there are specific examples of code where you're struggling to find a straightforward way to address an error, please feel free to post to the discussion section, and we should be able to suggest some good approaches.

[adam-grant-hendry]

Pyright adds pyright-specific control at the file level using # pyright: xxx style comments.

These are not currently working for the entire file

In my experience, there's usually a better way to deal with type errors than suppressing them.

There are edge cases where this is useful. In particular, one thing these methods do not cover well are unused imports in __init__.py files. It's often considered polite to import submodules directly into your package namespace so that users do not have to do deep .attribute lookups. In fact, Raymond Hettinger comments on this in PyCon 2015 talk Beyond PEP 8.

In this instance, without a file-level ignore (or scope-level), one must add # pyright: ignore[reportUnusedImport]'s everywhere in this file.

Rather than exclude the entire file from being linted (which I agree is bad practice), it would be nice to add a file-level ignore with the appropriate reportUnusedImport added. In fact, mypy supports requiring that a ignore statements be given a reason through enable_error_code = ignore-without-code.

Second, I believe this discourages gradual typing. Users may want to begin using pyright in pre-commit, however they are unable to providing proper linting for a given segment at a given time. If unable to ignore sections, pyright would have to be not used altogether or entire files would have to be ignored when it would be better to add specific ignore comments to each section.

Whether something is good or bad practice should be up to the purview of the project maintainers (and similarly monitored by project maintainers to prevent pushes being merged they disagree with). Otherwise, pyright becomes rather opinionated (like black) without a means for being able to choose where to use it.

[adam-grant-hendry]

These are not currently working for the entire file

Apologies, these work. I thought the syntax should be

# pyright: ignore[reportUnusedImport]

rather than

# pyright: reportUnusedImport=false

However, that will work only for all items in the same scope as the current file. It will not apply to, for instance, functions in the file. Hence, scope-level ignores are still unavailable.

[dsuch]

Thanks @erictraut - yes, I can understand it all.

There are no struggles on my end, I am aware of all the other options, whether static or runtime ones, this works.

It is simply that this additional capability could be very handy on its own and I opened the ticket because, like you said, perhaps enough people will express their interest as well. (My understanding being that you use GH tickets also to gather direct feedback and insights from programmers on what they are looking for).

Regards.

[erictraut]

Got it. Yes.

I generally don't keep enhancement request tickets open in the pyright issue tracker if we don't have any immediate intent to address them. If a closed ticket gets enough feedback (thumbs-up, etc.), then we revisit it.

In this particular case, I'm thinking that rather than closing the issue and waiting for feedback, it might be better to transfer it to the pylance-release repo. There it will be left open and perhaps receive more attention and discussion from other users. The number of pylance users is much higher than pyright users. (If you're not familiar with pylance, it's the full-featured language server extension for VS Code that builds upon pyright.)

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[spookyuser]

Genuinely not sure how to handle a library like dash which uses a weird _UNDEFINED type without scope level disabling of types

[spookyuser]

Thanks for your offer! To be honest, I wasn't really expecting help just wanted to show an example of an edge case where having scope level comments might be useful, since you never really know how libraries are going to implement types right now, especially since they don't seem to have caught on in the same way they have with typescript.

Also I think, philosophically, I would vote for users getting to decide how dangerous they want to be with their types, even if there are technically better ways of handling these kinds of issues.

Anyways, this is obviously free code, that I am benefitting from enormously, so I'm definitely bearing that in mind and just wanted to add my opinion here in case others feel the same way.

With that being said, I think the most minimal example I can think of is just a single element plotly dash website:

from dash import Dash, html, dcc
app = Dash(__name__)
app.layout = html.Div(children=[
    html.H1(children='Hello Dash'), # Throws type error
])

pip install dash==2.6.2

Thanks!

[erictraut]

It's important for us to understand the problems that pylance users are facing rather than simply implementing proposed solutions to those problems. When we understand the underlying problem, we're often able to come up with better solutions. In this case, you might think that scope-level comments would offer a remedy, but there are likely better solutions. That's why I asked for more details.

I'm not able to repro a type error with the above code. Can you confirm that you're able to repro an error with dash 2.6.2 and the above code sample?

[spookyuser]

Okay thanks for the info that's fair ♥️

Sorry that snippet didn't produce an error for me either, here is one that does (dash 2.6.2):

from dash import Dash, html, dcc

app = Dash(__name__)
app.layout = html.Div(
    children=[
        dcc.Graph(
            className="h-screen"
        )
    ]
)

[erictraut]

Thanks for the additional details. I've opened this bug report to track this issue.

[spookyuser]

No problem!