I am using pyright type checker and need to suppress warnings where e.g. numpy type stubs are insufficient to infer correct types. This can be accomplished with #type: ignore comment. However, I'd like any other issue to still be highlighted on the same line. For example mypy offers show_error_codes option that gives error codes that I can append to type:ignore comment to have only this specific issue suppressed.
I couldn't find such option in the docs https://github.com/microsoft/pyright/blob/main/docs/configuration.md . Is it possible to have specific error codes shown / ignored with pyright?
I just found out how to do that in both Pyright and Pylance.
When you run pyright it should give a detailed error report and show the corresponding diagnostic type, such as reportOptionalMemberAccess or reportOptionalSubscript. Same can be achieved by looking through the diagnostics reported by the language server (LSP).
You can then annotate the line with # pyright: ignore[reportOptionalMemberAccess] to disable this type of diagnostic.
Related
I'm having the following problem when trying to setup Substream Assembler filter with Substream Selector:
I have the following basic setup in the ADTF tool:
The input to Substream Assembly is simply a dummy filter, generating some random data and sending it to the output pin.
Substream assembly is supposed to take multiple inputs from the usual, non-substream returning filters and transform it into a substreams, if I understand it correctly, and then we can extract them with Substream Selector.
I cannot understand where this warning/error is coming from. Do you have any ideas? Thanks!
The warning seems to be just a bug, maybe based on initialization order issues (egg-chicken-issue).
As you can see above the Substream Selector, samples are processed. Just connect for example a Qt5 Media Description Display to the Substream Selector and you will see the values of P_tInt32.
If you use an invalid name, for example P_something, you will get the warning twice and no data. So yes, you can just ignore the warning during startup, everything is fine and will be fixed in upcoming releases.
When Pylint warns me about something, how can I know what settings it's applying? And what section of .pylintrc this setting goes in?
For example:
Used builtin function 'map'. Using a list comprehension can be clearer. (bad-builtin) is because bad-functions in [BASIC] contains map.
Missing function docstring (missing-docstring) is conditional on docstring-min-length in [BASIC].
invalid-name obeys several [BASIC] settings: variable-rgx, method-rgx, module-rgx, etc.
I expected to find this information in the Pylint documentation but it generally doesn't provide this information. For example, there's no link from the documentation of missing-docstring or invalid-names to the applicable options. With bad-builtin, the information is easy to find, but only because it's from a specific extension. The Pylint message wiki has explanations about what the message means, but not what brought it up. The comments in pylint --generate-rcfile don't relate the settings to warning codenames either (nothing there explains that e.g. bad-functions influences the bad-builtin message).
The reason I'm asking this is that in many cases, Pylint's conventions don't match my project's needs and conventions, and I want to tune it rather than ignore specific instances or ignore messages wholesale (so I'm not looking for disable=!). So how do I find what to tune?
How do I find what to tune?
So it seems like you're asking about how you can determine the combination of factors that lead to a pylint message being raised. Using the bad-builtin example, a warning message that is not listed at all in the .pylintrc, a helpful verbose message would be:
bad-builtin: Used builtin function 'map'. Using a list comprehension can be clearer.
---> (Hypothetical) VERBOSE OUTPUT:
bad-builtin was raised because the bad-functions setting in your .pylintrc under the [BASIC] section contains the function map. If you want to "tune" this behavior look here.
Short answer: I am not sure this exists.
When you run pylint my_file.py the first thing it should tell you is the configuration file it is using. From there, you want to find the .pylintrc in use or else you want to create it. Otherwise it will be using the default configuration. If pylint does not tell you what config you are using you can figure out your current pylintrc configuration by running something like:
pylint --generate-rcfile &> output.txt
When you inspect output.txt it should look like this example pylintrc. It is organized into different categories. You can get more info on this without generating an rcfile by running pylint --long-help. The sections include:
[MASTER]
[MESSAGES CONTROL]
[REPORTS]
[BASIC]
[ELIF]
[TYPECHECK]
[FORMAT]
[MISCELLANEOUS]
[VARIABLES]
[LOGGING]
[SIMILARITIES]
[SPELLING]
[IMPORTS]
[DESIGN]
[CLASSES]
[EXCEPTIONS]
I am not sure what you mean by, "The Pylint message wiki has explanations about what the message means, but not what brought it up." When I run pylint on a file or in a code base it tells me exactly where the offending line is.
Then I usually either:
Fix the warning
Disable the warning
Modify the .pylintrc to meet my needs
If you want to tune a specific message type but you are not sure how to do so, then I think you are right that is something that could be better documented. The question: Is XYZ warning message 'tunable'? Or is the only option to fix OR disable? This page lists the pylint features but I do not see anything about bad built-in, for example, let alone the options that are available to apply to a message type.
UPDATE: I am not sure what version of pylint you are on, but it looks like the bad-builtin was specifically addressed in pylint version 1.6. I was going to say we should look at what is going on in the actual source code to generate this message, but I think that requires figuring out what version of pylint you are on first, then digging into the code, then figuring out how to tune it? I agree that the docs can be more clear on how to tune specific warnings:
The bad-builtin check was moved into an extension.
The check was complaining about used builtin functions which were
supposed to not be used. For instance, map and filter were falling
into this category, since better alternatives can be used, such as
list comprehensions. But the check was annoying, since using map or
filter can have its use cases and as such, we decided to move it to an
extension check instead. It can now be enabled through
--load-plugins=pylint.extensions.bad_builtin.
I typically work in another text editor and simply copy and paste my work into Stata's command prompt. However, I have noticed a difference between the way the command prompt and the do file editor handle comments.
The code below reproduces the things I have discovered:
mata
//test comment
/* test comment 2 */
end
//test comment 3
*test comment 4
/* test comment 5*/
When run from the do file editor, the code runs without issue.
But when I run it after copying and pasting into the command prompt, I receive a number of r(3000) errors in mata and r(199) errors in Stata.
The sole exception is that the * comments in regular Stata work fine in both interfaces.
I also see that the // comment in mata gives an "expression invalid" error message along with the r(3000) notification, but I only receive the r(3000) message when I use the /* text */ comment. In regular Stata, both comment types that are not * give "/ is not a valid command name" messages along with the r(199).
My main question is:
What is the reason behind this difference? Is there anything I can do to suppress these errors?
Also, this is something like a red flag for me:
Are there other behaviors that differ when I run things via the command prompt rather than the do file editor?
The following Technical Note from the 16th Stata manual about Do-files explains:
"...The /* */, //, and /// comment indicators can be used in do-files and ado-files only; you may not use them interactively. You can, however, use the ‘*’ comment indicator interactively..."
So there is nothing surprising here. You can easily prevent errors like these by following the conventions. Just read the relevant section of the aforementioned manual for more details.
Only StataCorp knows for sure, but such differences probably arise from how Stata interprets the code internally when this is parsed from a do file or the command prompt.
See the following post for another (unrelated) example of an inconsistent behaviour:
Stata axis labels off-center when broken over multiple lines
Personally, after using Stata extensively for years, i have not noticed any other major differences when running code from do files and interactively.
Does anybody know whether it's possible to get the error-row of a file being compiled when the error occurs in an include file?
For example, I'm compiling a file, say abc.p, that uses def.i all over the place. At some point, I make a change to abc.p that causes a compile error in one of the includes, so the message says that the error occurred at line 123 of def.i, but I want to know at which line in abc.p that is. In other words, the line number where the offending include file is used.
Even though "Compiler:Get-File-Name(n)" returns def.i and "Compiler:File-Name" returns abc.p, both "Compiler:Get-Row(n)" as well as "Compiler:Error-Row" returns the line number in def.i.
Any ideas?
My guess would be to save the compiler listing or debug file and look at that.
Beyond that, I don't think there's a way to do it now - you need to submit an enhancement request to get this functionality.
My way of tracking this kind of error is with
compile source.p preprocess source.pp.
open source.pp in the procedure editor and check syntax.
This gives you the error location in the expanded source.
Once you have found that locate code that is not part of the include and search for that code in the original source.
Some executable files have resources marked "language neutral".
Is it possible to package these binaries using WiX?
The error I receive is: error LGHT0204 : ICE03: Invalid Language Id; Table: File, Column: Language, Key(s)
Setting the Product.Language attribute to '0' does not fix the problem.
You can suppress the retrieval of file information by passing this option to light.exe:
-sh
Suppress file information: do not get hash, version, language and
other file properties
To fix the original cause of the error, compare the incorrect language ID to the ones here.
Alternatively, if you verify that the Language Id is truly valid (I've never seen a case where the ICE was wrong though) then I would suppress the ICE before suppressing the hash information (-sh). The hash information is very important for your install. Instead use "light.exe -sice ICE03" to skip that ICE.
Also note that the ICE03 checks are pretty important so make sure you solve all the other issues befor supressing this it. There is a feature request out there to suppress only specific errors instead of the whole ICE.