| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| | |
add annotations to as_string method of Arguments
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
augmented assignments.
The change is similar to what was added for UnaryOps: a new method
called *type_errors* for both AugAssign and BinOp, which can be used
to retrieve type errors occurred during inference. Also, a new
exception object was added, BinaryOperationError.
|
| | | |
|
| | |
| |
| |
| | |
Previously trying to infer the Name(NotImplemented) returned an YES object.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is used to deduce the value of a node when used in a boolean context, which is useful
for both inference, as well as for data flow analysis, where we are interested
in what branches will be followed when the program will be executed.
`bool_value` returns True, False or YES, if the node's boolean value can't
be deduced. The method is used when inferring the unary operand `not`.
Thus, `not something` will result in calling `something.bool_value` and
negating the result, if it is a boolean.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
operations.
In exceptions, one object was added for holding information about a possible
UnaryOp TypeError, object called `UnaryOperationError`. Even though the name
suggests it's an exception, it's actually not one. When inferring UnaryOps,
we use this special object to mark a possible TypeError,
object which can be interpreted by pylint in order to emit a new warning.
We are also exposing a new method for UnaryOps, called `type_errors`,
which returns a list of UnaryOperationsError.
|
| | |
| |
| |
| | |
pylintrc.
|
| |/ |
|
| |
|
|
|
|
| |
The parent's fromlineno can be None when the parent
is a function retrieved from the builtins module,
which will not have the source code at hand.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reverts some changes added by a couple of changesets, making
the context caching and scoping to work as before.
The changesets in question are:
* 41b3bd589da0549ac061bc4c4b5d379cdbb1e10c
Replace copy_context with some dynamic scoping.
* 8d3c601
Remove context.lookupname; make it an argument to infer() when appropriate.
* partially reverts 048a42c.
Fix some deep recursion problems.
There were some problems with these changes, which led to horrendous
performance when dealing with multiple inference paths of the same names,
as seen in these Pylint issues:
* https://bitbucket.org/logilab/pylint/issue/395/horrible-performance-related-to-inspect
* https://bitbucket.org/logilab/pylint/issue/465/pylint-hangs-when-using-inspectsignature
* https://bitbucket.org/logilab/pylint/issue/430/pylint-140-execution-time-and-memory
The reverted changes assumed that a context it's only passed to callees
and then destroyed, thus InferenceContext.push always returned another inference context,
with the updated inference path so far. This is wrong, since contexts are sometimes
reused, so the original context, the one before the .push call need to have the same
cache key in its path (this is actually what's happening in these mentioned issues,
the same object is inferred over and over again, but with different contexts).
|
| |
|
|
| |
Also, this patch adds a new rule in the pylintrc for the CI gate.
|
| | |
|
| |
|
|
|
|
|
|
| |
This patch adds some inference tips for the mentioned builtins,
making calls such as 'list([4, 5, 6])` be inferred the same as `[4, 5, 6]`.
Previosly, inferring those objects resulted in an Instance of the given builtin,
without having access to their elements. This is useful, for instance, when trying
to infer slots defined with set, list of tuple calls (instead of their syntactic equivalents).
|
|
|
python setup.py develop now works.
|