Fix import astroid.scoped_nodes

[shadchin]

Steps

• For new features or bug fixes, add a ChangeLog entry describing what your PR does.
• Write a good description on what the PR does.

Description

Type of Changes

	Type
✓	🐛 Bug fix

Related Issue

[Pierre-Sassoulas]

Hmm, this a private function seeing it's name, if we want to make it public we should rename it. Why do you want to make it public exactly ?

[carlio]

For what it's worth, part of a recent change released as part of 2.9.1 caused an issue in pylint-django related to not being able to find this _is_metaclass.

_is_metaclass is not used in pylint-django but importing from scoped_nodes is. The move (which was scheduled for removal in astroid 3.0 according to the deprecation) seems to have had a knock-on effect.

For pylint-django, I just had to change from astroid import scoped_nodes to from astroid.nodes import scoped_nodes - that might be enough for your purposes @shadchin ? Apologies if I'm miles away from what you're attempting - just wanted to add some recent similar information.

[carlio]

Ah yes - I see it now : the old deprecated scoped nodes attempts to import it:
https://github.com/PyCQA/astroid/blob/main/astroid/scoped_nodes.py#L17

but it is not defined ('exported') in the new scoped nodes module
https://github.com/PyCQA/astroid/blob/main/astroid/nodes/scoped_nodes/__init__.py

So I think the correct fix is to remove line 17 from astroid.scoped_nodes rather than add it to the new module's exports.

[DanielNoord]

@carlio Thanks for the extra information and good job on fixing this so quickly in your own repo!

I think the best things to do for now is to add this as is done in this PR and publish a new version asap (@Pierre-Sassoulas). As the reporter in your repo notes, this breaking change is not to be expected in a 2.9.x release and was the result of me not checking the imports correctly. Sorry about that!
If we want to deprecate/privatize _is_metaclass we could do so, but that should be done in a different PR. We don't know who currently depends on it.

The move in #1302 was not intended to have any other side-effects other than allows us to split some files up. The imports should have stayed the same.

I'd say a quick release is necessary to prevent any other packages facing similar issues.

[Pierre-Sassoulas]

Let's release 2.9.2 ASAP.