| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
`Super.getattr()` (#782)
``infer_call_result`` can raise InferenceError but we were not handling that when retrieving
objects from the Super instance.
Close PyCQA/pylint#3529
|
| |
|
|
|
|
| |
before setting locals
|
|
|
|
|
| |
These new capabilities will allow inferring both the `property` builtin
as well as property attributes such as `.deleter` and `.setter`.
|
|
|
|
|
|
| |
with objectmodel
Close PyCQA/pylint#2776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class for PartialFunction
In the case where the node is a PartialFunction and its name is the same as the current statement's name,
avoid the statement deletion.
The problem was that a call to a function that has been previously called vit a functools.partial was wrongly inferred.
The bug comes from the _filter_stmts method of the LookupMixin class. The deletion of the current statement should not be
made in the case where the node is an instance of the PartialFunction class and if the node's name is the same as the statement's name.
This change also extracts PartialFunction from brain_functools into astroid.objects so that we remove a circular import problem.
Close PyCQA/pylint#2588
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the call sites where it is used
infer_call_result started recently to raise InferenceError for objects for which it could not find any returns.
Previously it was silently raising a StopIteration, which was especially leaking when calling builtin methods.
Since it is after all an inference method, it is expected that it could raise an InferenceError rather than
returning nothing.
Close PyCQA/pylint#2350
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Super objects in python have a __qualname__ attribute
so super nodes should have an equivalent qname method.
Prevents an error in upstream pylint
Close #533
|
|
|
|
| |
This reverts commit 06273cd07d4b3701998df7b2c656d1b029bdee8e.
|
|
|
|
| |
importing astroid.objects causes curcular imports with manager
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some of exceptions's attributes, such as .args and .message,
can't be inferred correctly since they are descriptors that get
transformed into the proper objects at runtime. This can cause issues
with the static analysis, since they are inferred as different than
what's expected. Now when we're creating instances of exceptions,
we're inferring a special object that knows how to transform those
runtime attributes into the proper objects via a custom object model.
Closes #81
|
|
|
|
|
|
|
|
| |
Through this model, astroid starts knowing special attributes of certain Python objects,
such as functions, classes, super objects and so on. This was previously possible before,
but now the lookup and the attributes themselves are separated into a new module,
objectmodel.py, which describes, in a more comprehensive way, the data model of each
object.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some of the messages were disabled in pylintrc, since they're not
very useful for our case. Other parameters, such as the number of
arguments / statements / attributes etc were configured so that they
won't be too restrictive for our codebase, since making the code
to respect them right now requires too much development changes,
which is not justified by the end result.
Closes issue #284.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major changes:
* AstroidError has an __init__ that accepts arbitrary keyword-only
arguments for adding information to exceptions, and a __str__ that
lazily uses exception attributes to generate a message. The first
positional argument to an exception is assigned to .message. The new
API should be fully backwards compatible in general.
* Some exceptions are combined or renamed; the old names are still
available.
* The OperationErrors used by pylint are now BadOperationMessages and
located in util.py.
* The AstroidBuildingException in _data_build stores the SyntaxError
in its .error attribute rather than args[0].
* Many places where exceptions are raised have new, hopefully more
useful error messages.
The only major issue remaining is how to propagate information into decorators.
|
|
|
|
|
|
| |
We're doing this in order to reduce the dependency hell which
occurs when a module such as bases.py wants to use classes
defined in node_classes.
|
|
|
|
|
|
| |
We did this because objects.Slice had more capabilities than
nodes.Slice, such as inferring the slice attributes (start, stop,
step) and it was used mostly for inferring the slice() builtin.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do this because of an internal distinction we're making between
AST nodes and inference objects. The following distinction might help
for understanding better where an AST node is used and where an inference object
is used:
* if the AST node can be used on its own, e.g. List, Tuple, etc,
then the AST can be used in the inference.
They have a syntactic display and can be written on its own,
e.g. "[]" is a valid list. That's why the inference of their
respective builtins (list, tuple, set etc) returns an AST node
when inferring.
* if the AST node is part of syntax and can't be used
on its own. This is the case for slices for instance, e.g "[2:3:4]".
In this case, trying to write "2:3:4" on its own will fail.
The respective builtin (slice) returns a custom object when inferring
and not an AST node per se.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
slices.
Closes issue #137.
|
| |
| |
| |
| | |
duplication. Closes issue #160.
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The cleanup consisted in a couple of changes:
* import only modules, not objects, in order
to not clutter the module namespace and to not
leak accidentally objects which aren't public API
for the said modules.
* use two spaces between module level functions
* move some mixins from astroid.node_classes in
the proper order, starting at the left,
not being last in the MRO.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This also implements an easier @cache decorator and removes @classproperty as
it only was used in an insignificant test.
--HG--
branch : no-logilab-common
|
|/ |
|
| |
|
| |
|
|
|
|
| |
raised when there's a problem with any argument of the super call (invalid types).
|
|
|
|
| |
type.
|
| |
|
|
|
|
| |
on the accessed object.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also adds support for understanding super calls.
astroid understands the zero-argument form of super, specific to
Python 3, where the interpreter fills itself the arguments of the call. Also, we
are understanding the 2-argument form of super, both for bounded lookups
(super(X, instance)) as well as for unbounded lookups (super(X, Y)),
having as well support for validating that the object-or-type is a subtype
of the first argument. The unbounded form of super (one argument) is not
understood, since it's useless in practice and should be removed from
Python's specification. Closes issue #89.
|