Skip to content

Planning for astroid 3.0 #1868

Closed as not planned
Closed as not planned
@cdce8p

Description

@cdce8p

With the breaking change for the new Try node we should probably start planning for version 3.0. We might as well use the major version bump to bundle other breaking changes as well.

How to update pylint

With the tight coupling between pylint and astroid, one of the main challenges will be how to keep the changes to pylint manageable. After each major change, we could

  • Release a new alpha version of astroid
  • Or pin a specific astroid commit in pylint directly.
astroid @ git+https://github.com/cdce8p/astroid.git@<commit>

Either way would help us keep the pylint changes reviewable.

Any bugfix release would only be merged in the pylint maintenance branch.

ToDo's

Maybe?

  • Better typing for Uninferable. Just an idea, with a breaking change we could change the class to UninferableType and Uninferable being an instance of it.
    Consider creating a UninferableType or _Uninferable class #1680
  • Make all arguments to __init__ and postinit for nodes keyword only args.
  • Remove explicit node exports from astroid.__init__.
  • Remove astroid.scoped_nodes module (not the package)

--
Those are just some things I had in mind. Happy to add additional things to it.
/CC: @Pierre-Sassoulas, @DanielNoord, @jacobtylerwalls

Open Questions

Until we're done with all changes, I don't think it make sense to release a new minor version. Should we release 2.13 before we start the process just to get the last features out there? Any bug fixes could be backported as usual. The breaking changes are mostly for downstream libraries, not astroid itself.

Metadata

Metadata

Assignees

No one assigned

    Labels

    MaintenanceDiscussion or action around maintaining astroid or the dev workflow

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions