Skip to content

Comments

Python: Remove some simple uses of points-to#21350

Draft
tausbn wants to merge 19 commits intomainfrom
tausbn/python-remove-simple-points-to
Draft

Python: Remove some simple uses of points-to#21350
tausbn wants to merge 19 commits intomainfrom
tausbn/python-remove-simple-points-to

Conversation

@tausbn
Copy link
Contributor

@tausbn tausbn commented Feb 19, 2026

WIP

Moves the classes/predicates that _actually_ depend on points-to to the
`LegacyPointsTo` module, leaving behind a module that contains all of
the metrics-related stuff (line counts, nesting depth, etc.) that don't
need points-to to be evaluated.

Consequently, `Metrics` is now no longer a private import in
`python.qll`.
The ones that no longer require points-to no longer import
`LegacyPointsTo`. The ones that do use the specific
`...MetricsWithPointsTo` classes that are applicable.
Removes the use of points-to for accessing various built-ins from three
of the queries. In order for this to work I had to extend the lists of
known built-ins slightly.
Uses a (perhaps) slightly coarser approximation of what modules are
imported, but it's probably fine.
This module (which for convenience currently resides inside
`DataFlowDispatch`, but this may change later) contains convenience
predicates for bridging the gap between the data-flow layer and the old
points-to analysis.
Uses the new `DuckTyping` module to handle recognising whether a class
is a container or not. Only trivial test changes (one version uses
"class", the other "Class").

Note that the ported query has no understanding of built-in classes. At
some point we'll likely want to replace `hasUnresolvedBase` (which will
hold for any class that extends a built-in) with something that's aware
of the built-in classes.
@tausbn tausbn force-pushed the tausbn/python-remove-simple-points-to branch from e53f35d to 700dce5 Compare February 20, 2026 15:04
Same comment as for the preceding commit. We lose one test result due to
the fact that we don't know what to do about `for ... in 1` (because `1`
is an instance of a built-in). I'm going to defer addressing this until
we get some modelling of built-in types.
Only trivial test changes.
Depending on whether other queries depend on this, we may end up moving
the exception utility functions to a more central location.
Approximates the behaviour of `Types::isNewStyle` but without depending
on points-to
@tausbn tausbn force-pushed the tausbn/python-remove-simple-points-to branch 2 times, most recently from b0d3167 to 45998d6 Compare February 20, 2026 15:57
These could arguably be moved to `Class` itself, but for now I'm
choosing to limit the changes to the `DuckTyping` module (until we
decide on a proper API).
Only trivial test changes.
Only trivial test changes.
For this one we actually lose a test result. However, this is kind of to
be expected since we no longer have the "precise" MRO that the points-to
analysis computes.

Honestly, I'm on the fence about even keeping this query at all. It
seems like it might be superfluous in a world with good Python type
checking.
@tausbn tausbn force-pushed the tausbn/python-remove-simple-points-to branch from 45998d6 to 6826c4e Compare February 20, 2026 16:21
This one is a bit more involved. Of note is the fact that it at present
only uses local flow when determining the origin of some value (whereas
the points-to version used global flow). It may be desirable to rewrite
this query to use global data-flow, but this should be done with some
care (as using "all unhashable objects" as the set of sources is
somewhat iffy with respect to performance). For that reason, I'm
sticking to mostly local flow (except for well behaved things like types
and built-ins).
Only trivial test changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant