We Keep Coding

Is IntelliJ Python 3 inspection "Expected a dictionary, got a dict" a false positive for super with **kwargs?

I use Python 3 and want to wrap argparse.ArgumentParser with a custom class that sets
formatter_class=argparse.RawDescriptionHelpFormatter by default. I can do this successfully, however IntelliJ IDEA 2017.1 with Python Plugin (PyCharm) gives a warning for the following code:
class CustomParser(argparse.ArgumentParser):
def __init__(self, formatter_class=argparse.RawDescriptionHelpFormatter, **kwargs):
# noinspection PyArgumentList
super().__init__(formatter_class=formatter_class, **kwargs) # warning in this line for the last argument if suppression comment above removed
If one removes the comment with the IntelliJ suppression command the warning on kwargs is "Expected a dictionary, got a dict", however it is working. Is this a false positive warning or can this be done better without the warning? Is there a real issue behind this warning that it helps avoiding?
Side question: Is there a difference in using
formatter_class = kwargs.pop('formatter_class', argparse.RawDescriptionHelpFormatter) instead of explicitly defining the named parameter in the signature? According to PEP20 more explicit in the signature is better, right?

Yes, that appears to be a false positive.
You asked about formatter_class=kwargs.pop('formatter_class', argparse.RawDescriptionHelpFormatter). Please don't do that. Mutating kwargs, which appears as the next argument, seems Bad. Additionally, default keyword args should be set to a simple constant rather than some mutable datastructure, as there is a big difference between evaluating at import time and evaluating at run time. See e.g. http://www.effbot.org/zone/default-values.htm . The usual idiom would be formatter_class=None in the signature, and then in the body you test for None and you mutate kwargs to your heart's content.

Marking all the virtual environment directories stored inside the project (e.g. ./venv) as excluded has solved it for me with PyCharm 2020.2.3.
To do so: right-click on the virtual environment directories in the project tree and select: Mark Directory as -> Excluded. Solution from https://youtrack.jetbrains.com/issue/PY-39715.

Python 2.6: encode() takes no keyword arguments

Hopefully simple question here, I have a value that based on if its unicode, must be encoded. I use the built in string.encode class
code is simple:
if value_t is unicode:
values += (value.encode('utf-8', errors='backslashreplace'), None)
continue
However it returns "encode() takes no keyword arguments"
I am running this in python 2.6, I couldn't find any documentation saying this didn't exist in 2.6
Is there a way for me to make sure it isn't being overwritten by an encode function in a different library? or some sort of solution to it.
It seems like you are able to use string.encode in 2.6 (https://docs.python.org/2.6/howto/unicode.html) so I am not really sure why it wouldn't be working. I am working on one file in a fairly big system, so I am worried this is somehow being overwritten. Either that or some module I need isn't installed..But i am lost

The Python docs for encode explain why you're seeing this issue. Specifically: Changed in version 2.7: Support for keyword arguments added

Since method signatures tend to change from version to version, You should always read the relevant documentation to version you are working with
From str.encode documentation for python 2.6, the method signature is:
str.encode([encoding[, errors]])
There is no errors keyword argument, but the second parameter can be used for the same purpose.

argparse optional argument before positional argument

I was wondering if it is possible to have a positional argument follow an argument with an optional parameter. Ideally the last argument entered into the command line would always apply toward 'testname'.
import argparse
parser = argparse.ArgumentParser(description='TAF')
parser.add_argument('-r','--release',nargs='?',dest='release',default='trunk')
parser.add_argument('testname',nargs='+')
args = parser.parse_args()
I would like both of these calls to have smoketest apply to testname, but the second one results in an error.
>> python TAF.py -r 1.0 smoketest
>> python TAF.py -r smoketest
TAF.py: error: too few arguments
I realize that moving the positional argument to the front would result in the correct behavior of the optional parameter, however this is not quite the format I am looking for. The choices flag looks like an attractive alternative, however it throws an error instead of ignoring the unmatched item.
EDIT:
I've found a hacky way around this. If anyone has a nicer solution I would appreciate it.
import argparse
parser = argparse.ArgumentParser(description='TAF')
parser.add_argument('-r','--release',nargs='?',dest='release',default='trunk')
parser.add_argument('testname',nargs=argparse.REMAINDER)
args = parser.parse_args()
if not args.testname:
args.testname = args.release
args.release = ''

As stated in the documentation:
'?'. One argument will be consumed from the command line if possible,
and produced as a single item. If no command-line argument is present,
the value from default will be produced. Note that for optional
arguments, there is an additional case - the option string is present
but not followed by a command-line argument. In this case the value
from const will be produced.
So, the behaviour you want is not obtainable using '?'. Probably you could write some hack using argparse.Action and meddling with the previous results.(1)
I think the better solution is to split the functionality of that option. Make it an option that requires an argument(but the option itself is optional) and add an option without argument that sets the release to 'trunk'. In this way you can obtain the same results without any hack. Also I think the interface is simpler.
In your example:
python TAF.py -r smoketest
It's quite clear that smoketest will be interpreted as an argument to -r. At least following unix conventions. If you want to keep nargs='?' then the user must use --:
$ python TAF.py -r -- sometest
Namespace(release=None, testname=['sometest']) #parsed result
(1) An idea on how to do this: check if the option has an argument. If it has one check if it is a valid test name. If so put into by hand into testname and set release to the default value. You'll also have to set a "flag" that tells you that this thing happened.
Now, before parsing sys.argv you must redirect sys.stderr. When doing the parsing you must catch SystemExit, check the stderr and see if the error was "too few arguments", check if the flag was set, if so ignore the error and continue running, otherwise you should reprint to the original stderr the error message and exit.
This approach does not look robust, and it's probably buggy.

Python dir command to determine the methods

I am using Python's dir() function to determine what attributes and methods a class has.
For example to determine the methods in wx.Frame, I use dir(wx.Frame)
Is there any command to determine the list of arguments for each method? For example, if I want to know what arguments belong to wx.Frame.CreateToolBar().

As mentioned in the comments, you can use help(fun) to enter the help editor with the function's signature and docstring. You can also simply use print fun.__doc__ and for most mature libraries you should get reasonable documentation about the parameters and the function signature.
If you're talking about interactive help, consider using IPython which has some useful extras. For instance you could type %psource fun to get a printout of the source code for the function fun, and with tab completion you could just type wx.Frame. and then hit TAB to see a list of all of the methods and attributes available within wx.Frame.

Even though GP89 seems to have already answered this question, I thought I'd jump in with a little more detail.
First, GP89's suggestion was the use Python's built-in help() method. This is a method you can use in the interactive console. For methods, it will print the method's declaration line along with the class' docstring, if it is defined. You can also access this with <object>.__doc__ For example:
>>> def testHelp(arg1, arg2=0):
... """This is the docstring that will print when you
... call help(testHelp). testHelp.__doc__ will also
... return this string. Here is where you should
... describe your method and all its arguments."""
...
>>> help(testHelp)
Help on function testHelp in module __main__:
testHelp(arg1, arg2=0)
This is the docstring that will print when you
call help(testHelp). testHelp.__doc__ will also
return this string. Here is where you should
describe your method and all its arguments.
>>>
However, another extremely important tool for understanding methods, classes and functions is the toolkit's API. For built-in Python functions, you should check the Python Doc Library. That's where I found the documentation for the help() function. You're using wxPython, whose API can be found here, so a quick search for "wx.Frame api" and you can find this page describing all of wx.Frame's methods and variables. Unfortunately, CreatteToolBar() isn't particularly well documented but you can still see it's arguments:
CreateToolBar(self, style, winid, name)
Happy coding!

Pylint best practices

Pylint looks like a good tool for running analysis of Python code.
However, our main objective is to catch any potential bugs and not coding conventions. Enabling all Pylint checks seems to generate a lot of noise. What is the set of Pylint features you use and is effective?

You can block any warnings/errors you don't like, via:
pylint --disable=error1,error2
I've blocked the following (description from http://www.logilab.org/card/pylintfeatures):
W0511: Used when a warning note as FIXME or XXX is detected
W0142: Used * or * magic*. Used when a function or method is called using *args or **kwargs to dispatch arguments. This doesn't improve readability and should be used with care.
W0141: Used builtin function %r. Used when a black listed builtin function is used (see the bad-function option). Usual black listed functions are the ones like map, or filter, where Python offers now some cleaner alternative like list comprehension.
R0912: Too many branches (%s/%s). Used when a function or method has too many branches, making it hard to follow.
R0913: Too many arguments (%s/%s). Used when a function or method takes too many arguments.
R0914: Too many local variables (%s/%s). Used when a function or method has too many local variables.
R0903: Too few public methods (%s/%s). Used when class has too few public methods, so be sure it's really worth it.
W0212: Access to a protected member %s of a client class. Used when a protected member (i.e. class member with a name beginning with an underscore) is access outside the class or a descendant of the class where it's defined.
W0312: Found indentation with %ss instead of %ss. Used when there are some mixed tabs and spaces in a module.
C0111: Missing docstring. Used when a module, function, class or method has no docstring. Some special methods like __init__ don't necessarily require a docstring.
C0103: Invalid name "%s" (should match %s). Used when the name doesn't match the regular expression associated to its type (constant, variable, class...).

To persistently disable warnings and conventions:
Create a ~/.pylintrc file by running pylint --generate-rcfile > ~/.pylintrc
Edit ~/.pylintrc
Uncomment disable= and change that line to disable=W,C

Pyflakes should serve your purpose well.

-E will only flag what Pylint thinks is an error (i.e., no warnings, no conventions, etc.)

Using grep like:
pylint my_file.py | grep -v "^C"
Edit :
As mentionned in the question, to remove the conventions advices from pylint output, you remove the lines that start with an uppercase C.
From the doc of pylint, the output consists in lines that fit the format
MESSAGE_TYPE: LINE_NUM:[OBJECT:] MESSAGE
and the message type can be:
[R]efactor for a “good practice” metric violation
[C]onvention for coding standard violation
[W]arning for stylistic problems, or minor programming issues
[E]rror for important programming issues (i.e. most probably bug)
[F]atal for errors which prevented further processing
Only the first letter is displayed, so you can play with grep to select/remove the level of message type you want.
I didn't use Pylint recently, but I would probably use a parameter inside Pylint to do so.