Question is simple, I have two lines in my Python script:
# pylint: disable=C0301, W0212
#!/usr/bin/env python
Both of them have to be on the first line otherwise they will not work.
How do you suggest I resolve this?
The following goes on the first line:
#!/usr/bin/env python
Pylint messages can go on any line. As the documentation says:
Is it possible to locally disable a particular message? This may be done by adding “#pylint: disable=W0123,E4567” at the desired block level or at the end of the desired line of code
So the message needs to be at the same block level (so the second line would work as well as that's the same block / scope). Furthermore the documentation says:
Is there a way to disable a message for a particular module only? Yes, you can disable or enable (globally disabled) messages at the module level by adding the corresponding option in a comment at the top of the file:
So it doesn't say: "first line of the file"; as long as the disable message is at the top of the file then it's fine.
Pylint disable comments do not need to be in the top line to work.
Related
I like to use ipdb to debug my code. I know we could stop the code on a file on a specific line with b(reak) file:lineno. That command will set a breakpoint in file at line 'no'.
Actually, I have inserted import ipdb; ipdb.set_trace() on a specific file. Each time I use the command s(tep), it executes and step into functions. My problem is it is too slow before seeing what I want to see. The stacktrace showed me lines I do not necessarily want to see. Then I was thinking to put a breakpoint on all files from a certain directory, i.e., b mydirectory/**. Therefore, eachtime I will execute c, it will show me all lines I want to see. However, I can't execute such command (i.e., b mydirectory/**). Could anyone have a solution to this problem?
Thanks!
P.S. The following picture show ton of those irrelevant files I don't want to see. In fact, it is normal to see those files, because I am working on a django project.
Please tell me if the question is unclear
import pdb; pdb.Pdb(skip=['mydirectory.*']).set_trace()
mydirectory have to be a python module, here is more info from the documentaion
The skip argument, if given, must be an iterable of glob-style module
name patterns. The debugger will not step into frames that originate
in a module that matches one of these patterns. [1]
source: https://docs.python.org/2/library/pdb.html#pdb.Pdb
When running an analysis I got the following error:
ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: Cannot analyse the
file'/home/user/project/package/module.py', details:
'java.lang.IllegalArgumentException: 302 is not a valid line for pointer.
File [moduleKey=com.project, relative=package/module.py,
basedir=/home/user/project] has 95 line(s)'
And that's correct, the file does have 95 lines. I checked the report generated by Pylint for that file (the last one in .sonar/pylint) and there are messages for two modules:
************* Module project.package.module
project/package/module.py:19: [C0301(line-too-long), ] Line too long (112/80)
project/package/module.py:1: [C0111(missing-docstring), ] Missing module docstring
************* Module django.contrib.admin.views.main
/home/user/.virtualenvs/project-env/local/lib/python2.7/site-
packages/django/contrib/admin/views/main.py:302: [W0201(attribute-defined-
outside-init), ChangeList.get_query_set] Attribute 'has_filters' defined outside __init__
So that's whence the 302nd line comes: the file in which the super class is defined. PyLint analyses the class in its entirely, for which it jumps to the virtualenv, then reports messages for both files. When the sensor processes that, it assumes there's only one file.
I think the sensor should be ignoring anything outside of the current file, since anything inside the project will be analysed eventually, and anything outside of the project will not be reported.
Is there a way to disable the analysis of dependencies in PyLint? (If so that's probably what Sonar should be doing, right?)
Ok, so the fix was simple enough: update Pylint.
The following Python fragment code gets analyzed by Pylint:
if type(result) is array.array:
read = result.tobytes()
... with the following error for the last line:
E:401,22: Instance of 'int' has no 'tobytes' member\
(but some types could not be inferred) (maybe-no-member)
The result variable is received from an external function. How can I change (correct) the code to make Pylint understand? Or how can I tell it that the result of the function can have other types than int? Or how can I tell it to ignore that particular line? (I favor an answer in this order of the questions)
For some reason, pylint doesn't get 'result' may be of the array type (and will be for sure under the 'if' branch). There is currently no way to tell pylint about that, though it will hopefully be possible at some point. So for now, you can only disable the warning for that specific line by adding # pylint: disable=maybe-no-member after the offending statement or right above it. For example:
if type(result) is array.array:
read = result.tobytes() # pylint: disable=maybe-no-member
or
if type(result) is array.array:
# pylint: disable=maybe-no-member
read = result.tobytes()
I disabled all no-member warnings by passing this command line option to pylint
--disable=E1101
While using PyLint you can generate a configuration pylint file using these command in your terminal
$ pylint --generate-rcfile > .pylintrc
the generated file handles the errors and warnings that you have to check.
for the no member in particular you can go to line 560, you can find that it ignored.
this configurations will be applied to all your code files.
and you can edit this configuration file, to meet your requirements.
Instead of
result.tobytes(),
use
getattr(result, 'tobytes')()
I am using pylint 0.27 with python 2.7.3. Pylint has a known bug which hits when it analyses code having a .next() call. As given in http://www.logilab.org/122793 link, it fails with the given traceback.
I cannot change my python and pylint versions but I would like to workaround this problem by disabling pylint on the piece of code that has .next() call by adding a #pylint: MAGIC comment in my code.
I could find support for disabling pylint checking on a file using #pylint: skip-file but I am interested at doing this at function level or rather at line level.
Any other workarounds are also welcomed!
You can accomplish this by adding the pylint comment as the first line of the function body like so:
def wont_raise_pylint():
# pylint: disable=W0212
some_module._protected_member()
some_module._protected_member()
def will_still_raise_pylint():
some_module._protected_member()
When I refactor code, I wrap the portion I have yet to touch
in a class ToDo and start that class with a directive
to ignore all messages. At the end of the class the directive
goes out of scope. MWE:
def unused_variable(foo=''):
"generate W0613"
class ToDo:
#pylint: disable = E, W, R, C
#disables W0613 and E0213
def unused_variable(foo=''):
"generate W0613 and E0213"
def main(foo=''):
"generate W0613"
To disable pylint entirely for a function without needing to enumerate each pylint violation code, specify all to the disable, eg:
def foo():
# pylint: disable=all
"""You put the disable right under the function signature
to disable pylint for the entire function scope.
"""
pass
Unfortunatly you won't be able to locally avoid the error you encounter.
One could expect to locate in the source code the offending piece of code, and then locally disable the involved message(s), but this won't work because it will still be run. This is because when locally disabling a message, the code detecting this message is run, only the message isn't be emitted in the end.
However, it may work if you globally disable this message (depending on the way it's implemented). In your case it seems unfortunatly that you would have to skip the whole 'logging' checker.
To sum up, to avoid your traceback you may either:
locally use pylint: skip-file, in which case every pylint's features will be activated but the whole offending file will be skipped
globally disable the 'logging' checker (--disable=logging), in which case the whole code (including the offending file) will be checked but without the 'logging' checker messages
In the perl debugger, if you repeatedly list segments of code taking you away from the current line, you can return to the current line by entering the command . (dot).
I have not been able to find anything comparable using the python PDB module. If I list myself away from the current line and want to view it again, it seems I have to either remember the line number that was currently executing (unlikely for me) or execute a statement (often undesirable).
Am I missing something?
Late but hopefully still helpful. Make the following alias:
alias ll u;;d;;l
Then whenever you type ll, pdb will list from the current position. It works by going up the stack and then down the stack, which resets 'l' to show from the current position. (This won't work if you are at the top of the stack trace.)
Tip: Permanent alias
To make the alias permanent, add the line into your .pdbrc-file in the user home directory (~/.pdbrc). This works with both pdb and ipdb.
In Python 3.2 and higher, you can use list . to reset the list location.
Source: Python Bug tracker #4179
This question is 7 years old now..
If there’s anyone who are curious about this problem, just use the dot
(pdb) l .
This now works.
Well, I don't think there's a command similar to . in perl debugger, but you can always find the current line using the where / w command. That will show you both the current (contextual) frame as well as the most recent frame, which I believe is where the debugger was triggered.